事务

3 月，跳不动了？>>> 最近遇到了事务不回滚的情况，我还考虑说JPA的事务有bug？ 我想多了....... 为了打印清楚日志，很多方法我都加tyr catch，在catch中打印日志。但是这边情况来了，当这个方法异常时候 日志是打印了，但是加的事务却没有回滚。 例： 类似这样的方法不会回滚 （一个方法出错，另一个方法不会回滚） ： if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); } } 下面的方法回滚（一个方法出错，另一个方法会回滚）： [html] view plaincopy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); throw new RuntimeException(); } } 或者： if(userSave){ try { userDao.save(user);

3 月，跳不动了？>>> 最近遇到了事务不回滚的情况，我还考虑说JPA的事务有bug？ 我想多了....... 为了打印清楚日志，很多方法我都加tyr catch，在catch中打印日志。但是这边情况来了，当这个方法异常时候 日志是打印了，但是加的事务却没有回滚。 例： 类似这样的方法不会回滚 （一个方法出错，另一个方法不会回滚） ： [html] view plain copy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); } } 下面的方法回滚（一个方法出错，另一个方法会回滚）： [html] view plain copy if(userSave){ try { userDao.save(user); userCapabilityQuotaDao.save(capabilityQuota); } catch (Exception e) { logger.info("能力开通接口，开户异常，异常信息："+e); throw new RuntimeException(); } } 或者： [html] view plain copy if

WHERE 和 HAVING 的基本区别： WHERE 在分组和聚集计算之前选取输入行（因此，它控制哪些行进入聚集计算）； HAVING 在分组和聚集之后选取分组行。 因此， WHERE 子句不能包含聚集函数（ 可以在子查询用聚集 ）； 因为试图用聚集函数判断哪些行应输入给聚集运算是没有意义的。相反， HAVING 子句总是包含聚集函数（严格说来，你可以写不使用聚集的 HAVING 子句， 但这样做很少有用。同样的条件用在 WHERE 阶段会更有效）。 事务： 事务最重要的一点是将多个步骤捆绑成了一个单一的、要么全完成要么全不完成的操作。步骤之间的中间状态对于其他并发事务是不可见的，并且如果有某些错误发生导致事务不能完成，则其中任何一个步骤都不会对数据库造成影响。 PostgreSQL实际上将每一个SQL语句都作为一个事务来执行。如果我们没有发出 BEGIN 命令，则每个独立的语句都会被加上一个隐式的 BEGIN 以及（如果成功） COMMIT 来包围它 窗口函数： 对于每一行，在它的分区中的行集被称为它的窗口帧 窗口函数只允许出现在查询的 SELECT 列表和 ORDER BY 子句中。它们不允许出现在其他地方，例如 GROUP BY 、 HAVING 和 WHERE 子句中。这是因为窗口函数的执行逻辑是在处理完这些子句之后。另外，窗口函数在非窗口聚集函数之后执行

MySQL事务 MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在一个商城系统中，用户执行购买操作，那么用户订单中应该加一条，库存要减一条，如果这两步由于意外只进行了其中一步那么就会发生很大的问题。而事务可以很好的解决这个问题。 事务是数据库处理操作，其中执行就好像它是一个单一的一组有序的工作单元。换言之在组内每个单独的操作是成功的，那么一个事务才是完整的。如果事务中的任何操作失败，整个事务将失败。 事务性质： 原子性：确保工作单位中所有操作都成功完成；否则，事务被中止，在失败时会回滚到事务操作以前的状态。 一致性：可确保数据库在正确的更改状态进行一个成功的提交事务。 隔离性：使事务相互独立的操作。 持久性：确保了提交事务的结果或系统故障情况下仍然存在作用。 TCL(事务控制语言)： begin; 操作; commit; BEGIN或START TRANSACTION; #显式地开启一个事务 COMMIT;或COMMIT WORK; #二者等阶。COMMIT会提交事务并使已对数据库进行的所有修改成为永久性的。未COMMIT的操作都存放在内存中，仅当前客户端可以查看到，其他客户端看不到，当前客户端关闭后就清空了 ROLLBACK;或ROLLBACK WORK; #二者等阶。回滚会结束用户的事务，并撤销正在进行的所有未提交的修改 SET AUTOCOMMIT=0

01 概述 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 OLTP 场景下通常要求具有很高的并发性。并发事务实际上取决于资源的使用状况，原则上应尽量减少对资源的锁定时间，减少对资源的锁定范围，从而能够尽量增加并发事务的数量，那么影响并发的因素有哪些呢？本文将从巨杉分布式数据库本身的机制以及隔离级别、数据库锁、参数、及实际例子进行详解，读完本文将对巨杉数据库并发性与锁机制有一个初步的了解。 02 隔离级别与并发性 在单用户环境中，每个事务都是顺序执行的，而不会遇到与其他事务的冲突。但是，在多用户环境下，多个事务并发执行。因此每个事务都有可能与其他正在运行的事务发生冲突。有可能与其他事务发生冲突的事务称为交错的或并行的事务，而相互隔离的事务称为串行化事务，这意味着同时运行它们的结果与一个接一个连续地运行它们的结果没有区别。在多用户环境下，在使用并行事务时，会发生四种现象： 丢失更新：这种情况发生在两个事务读取并尝试更新同一数据时

我们为什么要使用数据库的事务呢？使用事务有什么缺点呢？ 使用原因：保持数据的匹配和一致性。 缺点： 并发操作中过度使用事务影响性能，因为事务用到了锁技术。 我是李福春，今天我们来复习一下事务的特性。 你可以收获下图中的知识点。 下面我们发散一下。 事务特性 原子性： 要么全部成功要么全部失败 一致性： 保证事务的前后一致性 隔离性：事物之间的执行不能互相干扰 持久性： 事务终结的标志，内存的数据持久化到硬盘中 并发场景下事务出现的问题 脏读： 不可重复读 幻读： 依赖id的自增做为依据。 隔离级别 读未提交 隔离度最弱 脏读 不可重复度 幻读 读已提交 不可重复度 幻读 可重复读 数据库默认 幻读 可串行化 性能最低 没有问题 innodb mvcc 不能解决幻读 如何跟合理的使用事务 没有数据一致性要求场景 不使用事务 只有查询的场景: 不需要使用事务 更新记录表，然后更新统计表 不要使用事务， 使用事务触发或者定时任务； 内容繁杂的大事务 分拆成各种小事务，各种反向操作辅助 原创不易，转载请注明出处。 来源： https://www.cnblogs.com/snidget/p/12556761.html

2.2.1 并发一致性问题 常见并发并发一致性问题包括：丢失的修改、不可重复读、读脏数据、幻影读（幻影读在一些资料中往往与不可重复读归为一类）。 2.2.1.1 丢失修改 下面我们先来看一个例子，说明并发操作带来的数据的不一致性问题。 考虑飞机订票系统中的一个活动序列: 甲售票点（甲事务）读出某航班的机票余额A,设A=16. 乙售票点（乙事务）读出同一航班的机票余额A,也为16. 甲售票点卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 乙售票点也卖出一张机票,修改余额A←A-1.所以A为15,把A写回数据库. 结果明明卖出两张机票，数据库中机票余额只减少1。 归纳起来就是：两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失。前文（2.1.4数据删除与更新）中提到的问题及解决办法往往是针对此类并发问题的。但仍然有几类问题通过上面的方法解决不了，那就是： 2.2.1.2 不可重复读 不可重复读是指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。具体地讲，不可重复读包括三种情况： 事务T1读取某一数据后，事务T2对其做了修改，当事务1再次读该数据时，得到与前一次不同的值。例如，T1读取B=100进行运算，T2读取同一数据B，对其进行修改后将B=200写回数据库。T1为了对读取值校对重读B，B已为200

数据库存储引擎是数据库底层软件组织，数据库管理系统（DBMS）使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能，使用不同的存储引擎，还可以 获得特定的功能。现在许多不同的数据库管理系统都支持多种不同的数据引擎。MySql的核心就是存储引擎。 存储引擎查看 MySQL给开发者提供了查询存储引擎的功能，我这里使用的是MySQL5.1，可以使用： SHOW ENGINES 命令来查看MySQL使用的引擎，命令的输出为（我用的Navicat Premium）： 看到MySQL给用户提供了这么多存储引擎，包括处理事务安全表的引擎和出来了非事物安全表的引擎。 如果要想查看数据库默认使用哪个引擎，可以通过使用命令： SHOW VARIABLES LIKE 'storage_engine'; 来查看，查询结果为： 在MySQL中，不需要在整个服务器中使用同一种存储引擎，针对具体的要求，可以对每一个表使用不同的存储引擎。Support列的值表示某种引擎是否能使用：YES表示可以使用、NO表示不能使用、DEFAULT表示该引擎为当前默认的存储引擎 。下面来看一下其中几种常用的引擎。 ========================以上是转载的http://blog.csdn.net/zhangyuan19880606/article/details

写在前面：最早接触的MySQL是在三年前，那时候MySQL还是4.x版本，很多功能都不支持，比如，存储过程，视图，触发器，更别说分布式事务等复杂特性了。但从5.0(2005年10月)开始，MySQL渐渐步入企业级数据库的行列了；复制、集群、分区、分布式事务，这些企业级的特性，使得现在的MySQL，完全可以应用于企业级应用环境(很多互联网公司都用其作为数据库服务器，尽管节约成本是一个因素，但是没有强大功能作后盾，则是不可想象的)。虽然，MySQL还有很多不足，比如，复制、分区的支持都十分有限、查询优化仍需要改进，但是MySQL已经是一个足够好的DBMS了，更何况它是opensource的。这段时间没有事，出于好奇，略微的研究了一下MySQL，积累了一些资料，欲总结出来。这些资料打算分为两部分，上部主要讨论MySQL的优化，其中主要参考了《MySQL Manual》和《High Performance MySQL》，如果有时间，以后在下部分析一下MySQL的源码。如果你是MySQL高手，希望你不吝赐教；如果你是新手，希望对你有用。 第一章、MySQL架构与概念 1、MySQL的逻辑架构 最上面不是MySQL特有的，所有基于网络的C/S的网络应用程序都应该包括连接处理、认证、安全管理等。 中间层是MySQL的核心，包括查询解析、分析、优化和缓存等。同时它还提供跨存储引擎的功能

99% 的人都能看懂的「补偿」以及最佳实践 也许你对降级已经有了一些认识，这次，我们来聊一聊在保证对外高可用的同时，憋出的“内伤”该如何通过「补偿」机制来自行消化。 「补偿」机制的意义 以电商的购物场景为例： 客户端 ----> 购物车微服务 ----> 订单微服务 ----> 支付微服务。 这种调用链非常普遍。 那么为什么需要考虑补偿机制呢？ 正如之前几篇文章所说，一次跨机器的通信可能会经过 DNS 服务，网卡、交换机、路由器、负载均衡等设备，这些设备都不一定是一直稳定的，在数据传输的整个过程中，只要任意一个环节出错，都会导致问题的产生。 而在分布式场景中，一个完整的业务又是由多次跨机器通信组成的，所以产生问题的概率成倍数增加。 但是，这些问题并不完全代表真正的系统无法处理请求，所以我们应当尽可能的自动消化掉这些异常。 可能你会问，之前也看到过「补偿」和「事务补偿」或者「重试」，它们之间的关系是什么？ 你其实可以不用太纠结这些名字，从目的来说都是一样的。就是一旦某个操作发生了异常，如何通过内部机制将这个异常产生的「不一致」状态消除掉。 题外话：在笔者看来，不管用什么方式，只要通过额外的方式解决了问题都可以理解为是「补偿」，所以「事务补偿」和「重试」都是「补偿」的子集。前者是一个逆向操作，而后者则是一个正向操作。 只是从结果来看，两者的意义不同。「事务补偿」意味着“放弃”