事务的ACID属性，图解并发事务带来问题以及事务的隔离级别

事务的概述

　　事务是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID（原子性、一致性、隔离性和持久性）属性。事务是数据库运行中的逻辑工作单位，由DBMS中的事务管理子系统负责事务的处理。

操作流程

　　设想人生中的购物：

　　一、更新客户所购商品的库存信息
　　二、保存客户付款信息--可能包括与银行系统的交互
　　三、生成订单并且保存到数据库中
　　四、更新用户相关信息，例如购物数量等等

　　正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态--库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。
　　数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。

事务的ACID属性

　　原子性（Atomicity)：

　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。比如转账，要么转账成功，账户余额增加（减少）；要么转账失败，账户余额不变。

　　一致性(Consistency)：　　

　　事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。

　　隔离性(Isolation):

　　 由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为隔离性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。

　　持久性(Durability）:

　　事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。
 　　例如我们在使用JDBC操作数据库时，在提交事务方法后，提示用户事务操作完成，当我们程序执行完成直到看到提示后，就可以认定事务以及正确提交，即使这时候数据库出现了问题，也必须要将我们的事务完全执行完成，否则就会造成我们看到提示事务处理完毕，但是数据库因为故障而没有执行事务的重大错误。

并发事务处理带来的问题：

　　（1）丢失数据修改(Lost Update)

　　当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题。每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。
　　例如，T1和T2同时修改一条数据，T2的修改覆盖了T1的修改；　如果在T1之后第T2才能进行更改，则可以避免该问

　　（2）读“脏”数据，“脏读”(Dirty Reads)

　　一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被形象地叫做”脏读”。

　　例如：一个编辑人员T1正在更改电子文档。在更改过程中，另一个编辑人员T2复制了该文档（该复本包含到目前为止所做的全部更改）并将其分发给预期的用户。此后，第一个编辑人员T1认为所做的更改是错误的，于是删除了所做的编辑并保存了文档。分发给用户的文档包含不再存在的编辑内容，并且这些编辑内容应认为从未存在过。如果在第一个编辑人员确定最终更改前任何人都不能读取更改的文档，则可以避免该问题。

　　

　　

　　（3）不可重复读(Non-Repeatable Reads)

　　　

　　　　一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变！这种现象就叫做“不可重复读”。

　　　　指事务T2读取数据后，事务T1执行更新操作，使T2无法读取前一次结果。
　　　

　　（4）产生幽灵数据“虚读，幻读”(Phantom Reads)

　　一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”。

　　事务t2读取到了事务t1体提交的新增、删除数据，不符合隔离性。

　　幻读和不可重复读都是读取了另一条已经提交的事务（这点就脏读不同），所不同的是不可重复读查询的都是同一个数据项，而幻读针对的是一批数据整体（比如数据的个数）。

　　

　　

　　　　

隔离级别（限制由低到高, 性能从高到低）：

　　　　为了避免上面出现的几种情况，在标准SQL规范中，定义了4个事务隔离级别，不同的隔离级别对事务的处理不同。

　　（1）未授权读取

　　　　未授权读取也称为读未提交（Read Uncommitted）：允许脏读取，但不允许更新丢失。如果一个事务已经开始写数据，则另外一个事务则不允许同时进行写操作，但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。

　　　　不可避免 脏读、不可重复读、虚读。

　　　　

　　（2）授权读取

　　　　授权读取也称为读提交（Read Committed）：允许不可重复读取，但不允许脏读取。这可以通过“瞬间共享读锁”和“排他写锁”实现。读取数据的事务允许其他事务继续访问该行数据，但是未提交的写事务将会禁止其他事务访问该行。

　　　　可避免 脏读，不可避免 不可重复读、虚读。oracle采用读已提交。

　　（3）可重复读取（Repeatable Read）

　　　　可重复读取（Repeatable Read）：禁止不可重复读取和脏读取，但是有时可能出现幻读数据。这可以通过“共享读锁”和“排他写锁”实现。读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务。

　　　　可避免 脏读、不可重复读， 不可避免 虚读。mysql采用可重复读。

　　（4）序列化（Serializable）

　　　　序列化（Serializable）：提供严格的事务隔离。它要求事务序列化执行，事务只能一个接着一个地执行，不能并发执行。仅仅通过“行级锁”是无法实现事务序列化的，必须通过其他机制保证新插入的数据不会被刚执行查询操作的事务访问到。

　　　　可避免 脏读、不可重复读、虚读情况的发生。

　总结

　　　　

　　　　隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。对于多数应用程序，可以优先考虑把数据库系统的隔离级别设为Read Committed。它能够避免脏读取，而且具有较好的并发性能。尽管它会导致不可重复读、幻读和第二类丢失更新这些并发问题，在可能出现这类问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制

　　　　MySQL查询当前的隔离级别：SELECT @@tx_isolation;

　　

　　设置事务隔离级别（在开启事务前设置隔离级别！）

　　错误演示：

　　

　　正确设置：SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

　　

　　详见：https://dev.mysql.com/doc/refman/5.6/en/set-transaction.html