事务隔离： 为什么你改了我还看不见？

提到事务，大家肯定不会陌生，在和数据库打交道的时候我们总是会用到事务。最经典的例子就是给人转账，要经历几个步骤：查询余额，账户金额扣除与增加，余额更新并保存等等几个步骤。对于一个人来说，理解实现起来都很简单，无非就是有钱扣钱没钱抛出一个RuntimeException，扣完钱之后做个加减法保存一下。但是如果银行这么整的话，那么就乱了。

所以就会涉及到事务的概念，简单来说，事务是保证一组数据库操作，要么全部成功要么全部失败。而事务本身是在MySQL的引擎层实现的。

首先MySQL支持多引擎，但是多引擎并不是每一个引擎都支持事务，比如说被替换的MyISAM，这就是其原因之一。

今天的专栏将会以InnoDB为例，解析MySQL在事务支持方面的特定实现，并基于原理给出相应的实践建议，希望能加深大家对MySQL事务原理的理解。

隔离性与隔离级别

提到事务，你肯定会想到ACID(（ Atomicity、 Consistency、 Isolation、 Durability，即原子性、一致性、隔离性、持久性)，今天主要说的是隔离性。

当数据库同时有多个事务执行时候，就有可能出现以下几种情况：

• 脏读（ dirtyread）

事务A修改了一个数据，但是没有提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据(无效数据、更新但是没有提交成功的数据)

简单来说：抄别人没有检查的作业结果全错了

• 不可重复读（ non-repeatable read）

一个事务A读某数据的时候允许另一个事务B写同一个数据，B的写动作+提交动作(此处着重强调提交已经发生)发生在A的两次读之间，A的两次读得到的结果不一致。

不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁(如排它锁)，这会导致竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下(事务A和事务B分别使用一个快照)，避免不可重复读。

简单来说：别人作业还没写完就拿去抄，解决方法就是给别人写作业这件事情上锁，写完了释放锁，然后再抄。

• 幻读（ phantom read）

在同一个事务中，同一个查询多次返回的结果不一致(这里的结果指的是查询到的结果数量)。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。

为了解决以上三种问题，需要用到隔离
在谈隔离级别之前，大家首先需要知道，隔离得越严实，效率就会越低。因此在很多时候需要在二者之间寻找一个平衡点。SQL标准事务隔离级别包括：读未提交（ read uncommitted） 、读提交（ read committed） 、 可重复读（ repeatable read） 和串行化（ serializable ） 。 下面逐一解释：

• 读未提交：一个事务还没提交，就能被其他事务看见
• 读提交：一个事务提交之后，它做的变更才会被其他事务看到
• 可重复读：一个事务执行过程中看到的数据，和事务在启动中看到的数据是一致的。
• 串行化：读加读锁，写加写锁，读写分离。当出现读写锁冲突的时候呀，后访问的事务必须等前一个事务执行完成，才能继续执行。

其中读提交和可重读是比较难理解的，用一个例子说明。假设数据表T中只有一列，其中一行的值为1，下面是按照时间顺序执行两个事务的行为：

mysql> create table T(c int) engine=InnoDB;

insert into T(c) values(1);

我们可以看看在不同的隔离级别下。V1、V2、V3的返回值分别是什么：

• 如果隔离级别是读未提交，那么V1=2，这时候虽然事务B还没有提交，但是结果已经被A看到了。因此V2、V3也都是2。
• 如果隔离级别是读提交，那么V1=1，V2=2。事务B的更新在提交后才能被A看到。所以V3值也是2。
• 如果隔离级别是可重复读，则V1、V2是1，V3是2。之所以V2是1，遵循的即使这个要求：事务在执行期间看到的数据前后必须是一致的。
• 如果隔离级别是串行化，则在事务B执行”将1改成2“的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。所以从A的角度看，V1、V2值是1，V3的值是2。

实现本质是，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。

在可重复读隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。

在读提交隔离级别下，这个视图是在每个SQL语句开始执行时候创建的。

在读未提交隔离级别下，直接返回记录上的最新值，没有视图概念。

在串行化隔离级别下，直接用加锁的方式来避免并行访问。

我们可以看出在不同的隔离级别下，数据库行为是有所不同的。在数据库迁移的时候也要特别注意，要把隔离级别同步。

配置的方法很简单，使用show variables来查看当前的值。

mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+

事务隔离的实现

来看看事务隔离具体是怎么实现的，这里展开说明”可重复读“。

在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设一个值从1被按顺序改成了2、3、4，在回滚日志里面就会有类似下面的记录：

当前值是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view。如图所示，视图A、B、C里面，这一个记录值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制(MVCC)。对于read-viewA，要得到1，就必须将当前值依次执行图中所有的回滚操作得到。

回滚日志在不需要的时候才会被删除，不需要就是指没有事务涉及到的时候。

建议尽量不要使用长事务，原因是：

长事务意味着系统里面存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。而且因为保证回滚段落的隔离，长事务还要占用锁资源，耽误整个数据库的使用。

事务启动方式

很多时候呀长事务是因为操作不当产生的，以下几种是正确的启动方式：

1. 显示启动事务语句，begin或start transaction。配套的提交语句时commit，回滚语句时rollback。
2. set autocommit=0， 这个命令会将这个线程自动提交关掉。意味着如果你只执行一个select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行commit或rollback语句，或者断开连接。

有些客户端连接框架会默认连接成功后先执行set autocommit=0的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。

因此建议总是使用set autocommit=1,通过显式语句的方式来启动事务。

对于一个需要频繁使用事务的业务，就可以使用第二种方式，因为不需要在每个事务开始时候使用begin，减少了语句的交互次数。如果有这个顾虑，建议使用commit work and chain语法。

在autocommit为1的情况下， 用begin显式启动的事务， 如果执行commit则提交事务。如果执行commit work and chain， 则是提交事务并自动启动下一个事务， 这样也省去了再次执行begin语句的开销。 同时带来的好处是从程序开发的角度明确地知道每个语句是否处于事务中。