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

提到事务，必然会联想到和数据库打交道的时候，如果要给同学转账的话，我们要经历几个步骤：查询余额，账户金额扣除与增加，余额更新并保存等等几个步骤。对于一个人来说，理解起来，实现起来都很简单，不就是有钱扣钱，没钱throw一个RuntimeException嘛，扣完钱做个加减法save一下。但是如果是在蚂蚁金服这种大公司的话，就会乱了。

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

首先我们要知道Mysql支持多引擎，但是多引擎并不是每一个引擎都支持事务，比如说被替换的MylSAM，这就是其原因之一。

今天的专栏将会以InnoDB，解析Mysql在事务支持方面的特定实现，并且基于原理给出响应的时间建议，希望彼此能更好的理解事务。

隔离性与隔离级别

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

当数据库同时进行多个事务的时候，就会出现以下几种情况：

1. 脏读(dirty read)

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

简单来就是：抄了别人没检查的作业，结果全错了。

2. 不可重复读(non-repeatable read)

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

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

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

3. 幻读(phantom read)

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

 
 
为了解决以上三种扯淡的问题，就得用到隔离。

在讲怎么隔离之前，先说一下，隔离的越厉害，效率就越低。因此我们需要有一个平衡点，sql标准的事务隔离级别包括：读未提交（read uncommitted）、 读提交（read committed）、可重复读（repeatable read）和串行化（serializable ） 下面来进行一一解释：

• 读未提交：一个事务还没提交，就能被其他事务看见
• 读提交：一个事务提交之后，它做的变更才会被其他事务看到
• 可重复读：一个事务执行过程中看到的数据，和事务在启动中看到的数据是一致的。
• 串行化：读加读锁，写加写锁，读写分离。

假设数据表T中只有一列，其中一行值为1，下面是按照时间顺序执行两个事务的行为。

mysql> create table T2(c int) engine = InnoDB;
Query OK, 0 rows affected (0.17 sec)

mysql> insert into T2(c) values(1);
Query OK, 1 row affected (0.01 sec)

我们可以看看在不同的隔离级别下，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中，每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设我们把1，按照顺序改变成了2 3 4 ，回滚日志如下：

当前值是4，但是查询的时候，不同时刻的启动的事务会有不同的read-view。如图所示，视图A，B，C里面，这一个记录的值分别为1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制(MVCC)。对于read-view A，要得到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语法。