MySQL数据库事务

事务（Transaction）是并发控制的基本单位。所谓事务，就是一个操作序列，要么全部执行，要么都不执行，它是一个不可分割的工作单位。比如下单，商品库存减少和生成用户订单，这两个操作要么都执行要么都不执行，所以应该把它们视为一个事务。

事务的提出主要是为了解决并发情况下保持数据一致性的问题，它有以下几个特性：

• 原子性：事务中的包含的操作被视为一个逻辑单元，要么全部成功，要么全部失败。
• 一致性：事务只有合法的数据可以被写入数据库，否则事务应该将其回滚到最初状态。
• 隔离性：事务允许多个用户对同一个数据进行并发访问，而不破坏数据的正确性和完整性。同时事务的修改必须与其他事务的修改相互独立。
• 持久性：事务完成之后，它对系统的影响是永久性的，即使出现致命的系统故障也将保持一致。

以上特性，原子性是基础，隔离性是手段，一致性和持久性是目标。

既然隔离性是手段，而要求多个用户之间的并发数据操作又很难保证互不干扰，那就必须要有一个共同遵守的规范。这个规范就是事务隔离级别。

1. 隔离级别

MySQL标准定义了4种隔离级别，低的隔离级别一般支持更高的并发处理，拥有更低的系统开销。由低到高：Read Uncommitted < Read Committed < Repeatable Read < Serializable。

隔离级别的主要目的是处理数据一致性，它是保证一致性的重要手段和工具。假如有事务A和B并发执行，在保证一致性的时候，就可能会遇到脏读、不可重复读和幻读等问题。

• 脏读：读到了脏数据，事务A读取事务B未提交的数据，并又在这个基础上做了其他操作（禁止）。
• 不可重复读：事务A读取了事务B已提交的修改数据（正常）。
• 幻读：事务A读取了事务B已提交的新增数据（正常）。

由上面可以看出，脏读是必须禁止的，不可重复读和幻读虽然对当前事务来说不可理解，但对于最终结果来说是正确的，没有影响到数据的准确性，可以不作考虑。所以说，数据库起码要做到不可脏读。如果对数据一致性要求非常高，隔离界别就要达到SERIALIZABLE了，但一般不需要，因为它会明显降低数据库的并发性能。MySQL默认的隔离级别是REPEATABLE READ。

在MySQL中，事务有两种模式：自动提交（默认）和非自动提交。

• 自动提交：每一条语句执行完把它做出的修改立刻自动提交给数据库，并使之持久化。
• 非自动提交：用start transaction挂起自动提交模式，之后任何语句都将成为事务的一部分，直到发出commit或rollback语句来提交或撤销。

总的来说start transaction和DDL(数据定义语句)都会隐式地提交一个事务，因此这些语句不能放在事务中执行。DDL基本上就是除了增删改查之外的语句。

2. 事务嵌套与传播方式

事务嵌套就是在A函数中调用了B函数，A函数使用了事务，并且在事务中调用了B函数，B函数也有事务，这样就出现了事务嵌套，PDO API事务函数基本是包含start transaction的，如果框架事务开始和提交不做特殊处理，使用原生的PDO API事务函数，互相嵌套的时候就会造成隐式的提交，这样事务肯定就是错误的。那么碰到这种问题怎么处理呢？通常我们需要在应用层去处理，一般框架的ORM都会对此进行处理。

这里介绍一种思路，在beginTransaction函数中，用一个变量level记录当前嵌套的级别，level=1时说明没有嵌套，直接start transaction就可以了，如果大于1，就是有嵌套了，创建一个savepoint(mysql提供的功能)，savepoint就是事务记录点，当需要回滚时可以只回滚到这个点。最后是commit函数的处理，如果level=1直接回滚，否则回滚到savepoint。
beginTransaction和commit是配对的处理方式。更简单粗暴的方式是把嵌套事务合并到外部事务中，不考虑嵌套。

嵌套事务涉及一个嵌套的规则，就是说当一个方法A调用另一个方法B时，事务操作的方法，我们称之为事务传播规则，一共有7种规则，最常见的是PROPAGATION_REQUIRED这个事务传播行为，即如果A没有事务，就新建一个事务；如果有，就把B加入当前事务。