数据库事务

数据库事务（一）

概述

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

操作流程

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

数据库事务的ACID属性

原子性（atomic）
　　事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。
一致性（consistent）
　　事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。
隔离性（insulation）
　　由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。防止数据丢失
持久性(durability）
　　事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。

数据库事务（二）

数据并发的问题 
    一个数据库可能拥有多个访问客户端，这些客户端都可以并发方式访问数据库。数据库中的相同数据可能同时被多个事务访问，如果没有采取必要的隔离措施，就会导致各种并发问题，破坏数据的完整性。这些问题可以归结为5类，包括3类数据读问题（脏读、幻象读和不可重复读）以及2类数据更新问题（第一类丢失更新和第二类丢失更新）。下面，我们分别通过实例讲解引发问题的场景。

脏读（dirty read） 
    在讲解脏读前，我们先讲一个笑话：一个有结巴的人在饮料店柜台前转悠，老板很热情地迎上来：“喝一瓶？”，结巴连忙说：“我…喝…喝…”，老板麻利地打开易拉罐递给结巴，结巴终于憋出了他的那句话：“我…喝…喝…喝不起啊！”。在这个笑话中，饮料店老板就对结巴进行了脏读。 
A事务读取B事务尚未提交的更改数据，并在这个数据的基础上操作。如果恰巧B事务回滚，那么A事务读到的数据根本是不被承认的。来看取款事务和转账事务并发时引发的脏读场景：
     

时间	转账事务A	取款事务B
T1		开始事务
T2	开始事务
T3		查询账户余额为1000元
T4		取出500元把余额改为500元
T5	查询账户余额为500元（脏读）
T6		撤销事务余额恢复为1000元
T7	汇入100元把余额改为600元
T8	提交事务

　　在这个场景中，B希望取款500元而后又撤销了动作，而A往相同的账户中转账100元，就因为A事务读取了B事务尚未提交的数据，因而造成账户白白丢失了500元。

不可重复读（unrepeatable read） 
   不可重复读是指A事务读取了B事务已经提交的更改数据。假设A在取款事务的过程中，B往该账户转账100元，A两次读取账户的余额发生不一致：

 

时间	取款事务A	转账事务B
T1		开始事务
T2	开始事务
T3		查询账户余额为1000元
T4	查询账户余额为1000元
T5		取出100元把余额改为900元
T6		提交事务
T7	查询账户余额为900元（和T4读取的不一致）

 　　在同一事务中，T4时间点和T7时间点读取账户存款余额不一样。
幻象读（phantom read） 
    A事务读取B事务提交的新增数据，这时A事务将出现幻象读的问题。幻象读一般发生在计算统计数据的事务中，举一个例子，假设银行系统在同一个事务中，两次统计存款账户的总金额，在两次统计过程中，刚好新增了一个存款账户，并存入100元，这时，两次统计的总金额将不一致：  

时间	统计金额事务A	转账事务B
T1		开始事务
T2	开始事务
T3	统计总存款数为10000元
T4		新增一个存款账户，存款为100元
T5		提交事务
T6	再次统计总存款数为10100元（幻象读）

　　如果新增数据刚好满足事务的查询条件，这个新数据就进入了事务的视野，因而产生了两个统计不一致的情况。 
　　幻象读和不可重复读是两个容易混淆的概念，前者是指读到了其它已经提交事务的新增数据，而后者是指读到了已经提交事务的更改数据（更改或删除），为了避免这两种情况，采取的对策是不同的，防止读取到更改数据，只需要对操作的数据添加行级锁，阻止操作中的数据发生变化，而防止读取到新增数据，则往往需要添加表级锁——将整个表锁定，防止新增数据。

第一类丢失更新 
    A事务撤销时，把已经提交的B事务的更新数据覆盖了。这种错误可能造成很严重的问题，通过下面的账户取款转账就可以看出来： 
    

时间	取款事务A	转账事务B
T1	开始事务
T2		开始事务
T3	查询账户余额为1000元
T4		查询账户余额为1000元
T5		汇入100元把余额改为1100元
T6		提交事务
T7	取出100元把余额改为900元
T8	撤销事务
T9	余额恢复为1000元（丢失更新）

　　A事务在撤销时，“不小心”将B事务已经转入账户的金额给抹去了。 
第二类丢失更新 
　　A事务覆盖B事务已经提交的数据，造成B事务所做操作丢失：  

时间	转账事务A	取款事务B
T1		开始事务
T2	开始事务
T3		查询账户余额为1000元
T4	查询账户余额为1000元
T5		取出100元把余额改为900元
T6		提交事务
T7	汇入100元
T8	提交事务
T9	把余额改为1100元（丢失更新）

    上面的例子里由于支票转账事务覆盖了取款事务对存款余额所做的更新，导致银行最后损失了100元，相反如果转账事务先提交，那么用户账户将损失100元。

 

数据库事务（三）

 

事务隔离级别 
    尽管数据库为用户提供了锁的DML操作方式，但直接使用锁管理是非常麻烦的，因此数据库为用户提供了自动锁机制。只要用户指定会话的事务隔离级别，数据库就会分析事务中的SQL语句，然后自动为事务操作的数据资源添加上适合的锁。此外数据库还会维护这些锁，当一个资源上的锁数目太多时，自动进行锁升级以提高系统的运行性能，而这一过程对用户来说完全是透明的。 
    ANSI/ISO SQL 92标准定义了4个等级的事务隔离级别，在相同数据环境下，使用相同的输入，执行相同的工作，根据不同的隔离级别，可以导致不同的结果。不同事务隔离级别能够解决的数据并发问题的能力是不同的。 
        表 1 事务隔离级别对并发问题的解决情况 

隔离级别	脏读	不可 重复读	幻象读	第一类丢失更新	第二类丢失更新
READ UNCOMMITED	允许	允许	允许	不允许	允许
READ COMMITTED	不允许	允许	允许	不允许	允许
REPEATABLE READ	不允许	不允许	允许	不允许	不允许
SERIALIZABLE	不允许	不允许	不允许	不允许	不允许

    事务的隔离级别和数据库并发性是对立的，两者此增彼长。一般来说，使用READ UNCOMMITED隔离级别的数据库拥有最高的并发性和吞吐量，而使用SERIALIZABLE隔离级别的数据库并发性最低。

    SQL 92定义READ UNCOMMITED主要是为了提供非阻塞读的能力，Oracle虽然也支持READ UNCOMMITED，但它不支持脏读，因为Oracle使用多版本机制彻底解决了在非阻塞读时读到脏数据的问题并保证读的一致性，所以，Oracle的READ COMMITTED隔离级别就已经满足了SQL 92标准的REPEATABLE READ隔离级别。

    SQL 92推荐使用REPEATABLE READ以保证数据的读一致性，不过用户可以根据应用的需要选择适合的隔离等级。