事务隔离与可重复读的实现原理

一、前言

简单来说，事务就是要保证一组数据库操作，要么全部成功，要么全部失败。

在MySQL中，事务支持是在引擎层实现的。MySQL是一个支持多引擎的系统，但并不是所有的引擎都支持事务。比如MySQL原生的MyISAM引擎就不支持事务，这也是MyISAM被InnoDB取代的重要原因之一。

下面会以InnoDB为例。

二、隔离性与隔离级别

提到事务，肯定会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）

下面来看其中的 I，也就是“隔离性”。

当数据库上有多个事务同时执行的时候，就可能出现如下问题

• 脏读（dirty read）：读取了未提交的数据（涉及数据修改）
• 不可重复读（non-repeatable read）：同个事务中多次读取的同一条数据的值不同（涉及数据修改）
• 幻读（phantom read）：同个事务中相同条件下查出的数据条数不同（涉及数据增删）

为了解决这些问题，就有了“隔离级别”的概念。

在谈隔离级别之前，首先要知道，隔离级别越高，效率就会越低。因此要在二者之间寻找一个平衡点。
SQL标准的事务隔离级别包括：读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）。

• **读未提交（read uncommitted）：**一个事务还没提交时，它做的变更就能被别的事务看到。
• **读提交（read committed）：**一个事务提交之后，它做的变更才会被其他事务看到。
• 可重复读（repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
• **串行化（serializable ）：**顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

在MySQL里，有两个“视图”的概念：

• 一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view … ，而它的查询方法与表一样。
• 另一个是InnoDB在实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。

它没有物理结构，作用是事务执行期间用来定义“我能看到什么数据”。

这些隔离级别在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准；

• 在“读未提交”隔离级别下直接返回记录上的最新值，**没有视图 **概念；
• 在“读提交”隔离级别下，这个视图是在每个 **SQL语句开始执行时 **创建的；
• 在“可重复读”隔离级别下，这个视图是在 **事务启动时 **创建的，整个事务存在期间都用这个视图；
• 在“串行化”隔离级别下，直接用加锁的方式来避免并行访问。

三、事务隔离的实现

接下来看事务隔离具体是怎么实现的（即视图是怎么实现的）。这里展开说明“可重复读”。
​

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

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

图1. 行状态变更图
​

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

• 回滚日志什么时候删除？

系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。就是当系统里没有比这个回滚日志更早的 read-view 的时候。

• 尽量避免使用长事务

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

在MySQL 5.5及以前的版本，回滚日志是跟数据字典一起放在ibdata文件里的，即使长事务最终提交，回滚段被清理，文件也不会变小。

四、“可重复读”是如何实现的？

4.1 “快照”在MVCC里是如何工作的？

MVCC：Multiversion Concurrency Control ，即多版本并发控制技术。MySQL中基于乐观锁理论实现隔离级别的方式，用于实现读提交和可重复读隔离级别。

在可重复读隔离级别下，事务在启动的时候就存一个"快照"。注意，这个快照是基于整库的。但是这个"快照"并不是存的整个库的数据。
​

InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。而每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。同时，旧的数据版本要保留，并且在新的数据版本中，能够有信息可以直接拿到它。

也就是说，数据表中的一行记录，其实可能有多个版本(row)，每个版本有自己的 row trx_id。

如图所示，就是一个记录被多个事务连续更新后的状态：

图2： 数据版本变更图
​

图中虚线框里是同一行数据的4个版本，当前最新版本是V4，k的值是22，它是被transaction id 为25的事务更新的，因此它的row trx_id也是25。

图中的三个虚线箭头，就是 undo log；而V1、V2、V3并不是物理上真实存在的，而是每次需要的时候根据当前版本和undo log计算出来的。比如，需要V2的时候，就是通过V4依次执行U3、U2算出来。

4.1.1 InnoDB是如何定义一致性视图（read view）的？

根据以上多版本和 row trx_id 的概念，来看一下，InnoDB是如何定义快照（read view）的。

按照可重复读的定义，一个事务启动的时候，能够看到所有已经提交的事务结果，和自己更新的数据。但是看不到之后启动的事务修改的数据。
​

在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值（不一定是数组中的）加1记为高水位。这个视图数组和高水位，就组成了当前事务的一致性视图（read-view）。
​

而数据版本的可见性规则，就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的。这个视图数组把所有的 row trx_id 分成了几种不同的情况。

图3：数据版本可见性规则（注：图中数组为事务20的活跃ID数组）

这样，对于当前事务的启动瞬间来说，一个数据版本的 row trx_id，有以下几种可能：

1. 如果落在绿色部分，表示这个版本是已提交的事务，这个数据是可见的；
2. 如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；
3. 如果落在黄色部分，那就包括两种情况
   1. 若 row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见（如图2中的10、15、20）；
   2. 若 row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见（如图2中12、18等）。

比如，对于图2中的数据来说，如果有一个事务，它的低水位是18，那么当它访问这一行数据时，就会从V4通过U3计算出V3，所以在它看来，这一行的值是11。

简言之，一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

1. 版本未提交，不可见；
2. 版本已提交，但是是在视图创建后提交的，不可见；
3. 版本已提交，而且是在视图创建前提交的，可见。

有了这个声明后，系统里面随后发生的更新，就跟这个事务看到的内容无关了。
因为之后的更新，生成的版本一定属于上面的2或者3(a)的情况，而对它来说，这些新的数据版本是不存在的，所以这个事务的快照，就是“静态”的了。
InnoDB就是利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。

4.2 可重复读下的查询逻辑

图4：事务A查询数据逻辑图
​

图示说明：

1. 事务A开始前，系统里面只有一个活跃事务ID是99；
2. 事务A、B、C的版本号分别是100、101、102，且当前系统里只有这四个事务；
3. 三个事务开始前，(1，1）这一行数据的row trx_id是90。

更新顺序是，事务C先更新，事务B后更新；事务A查询时，C已经提交，事务B未提交。
​

下面看事务A查询语句读取数据的流程：

1. 查到当前版本的数据（1，3），row trx_id=101，比高水位100大，处于红色区域不可见；
2. 找到上一个历史版本，row trx_id=102，比高水位100大，处于红色区域不可见；
3. 继续找上一个历史版本，row trx_id=90，比低水位100小，处于绿色区域，可见，查到结果为1。

事务A不论在什么时候查询，看到这行数据的结果都是一致的，所以称之为一致性读。
​

以上是基于代码逻辑的判断过程，比较麻烦，下面通过 4.1.1 中的简化版本来理解这个过程：

简言之，一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

1. 版本未提交，不可见；
2. 版本已提交，但是是在视图创建后提交的，不可见；
3. 版本已提交，而且是在视图创建前提交的，可见。

• （1，3）未提交，不可见；
• （1，2）提交了，但是是在视图数组创建后提交的，不可见；
• （1，1）是在视图数组创建之前提交的，可见。

4.3 可重复读下的更新逻辑

4.3.1 场景一

图5：事务B更新逻辑图

两个“?”处结果分别为：事务101（1，3）；k = 3。
​

这里如果只根据一致性视图来判断，会是：事务101（1，2）；k = 2。
​

那么，怎么会得出（1，3）来？
如果事务B在更新之前查询一次数据，这个查询返回的 k 的值确实是1。但是，当它要去更新数据的时候，就不能再在历史版本上更新了，否则事务C的更新就丢失了。因此，事务B此时的 set k=k+1 是在（1，2）的基础上进行的操作。

这里就用到了这样一条规则：更新语句（update）都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
因此，在更新的时候，当前读拿到的数据是(1，2)，更新后生成了新版本的数据(1，3)，这个新版本的 row trx_id是101。所以，在执行事务B查询语句的时候，一看自己的版本号是101，最新数据的版本号也是101，是自己的更新，可以直接使用，所以查询得到的 k 的值是3。

4.3.2 当前读

上面提到了一个概念，叫作当前读。其实，除了update语句外，select语句如果加锁，也是当前读。
所以，如果把事务A的查询语句 select * from t where id=1 修改一下，加上 lock in share mode 或 for update，也都可以读到版本号是101的数据，返回的k的值是3。下面这两个select语句，就是分别加了读锁（S锁，共享锁）和写锁（X锁，排他锁）。

select k from t where id = 1 lock in share mode;
select k from t where id = 1 for update;

4.3.3 场景二

假设图4中得事务C不是马上提交，而是变成下面的事务C’，会怎样？
​

图6：事务A、B、C’的执行流程

对应逻辑图如下：

图7：事务A、B、C’执行逻辑图

事务C’，更新后并没有马上提交，在它提交前，事务B的更新语句先发起了。虽然事务C’还没提交，但是(1,2)这个版本也已经生成了，并且是当前的最新版本。那么，事务B的更新语句会怎么处理呢？
​

这时，根据“两阶段锁协议”（在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议），事务C’没提交，也就是说(1,2)这个版本上的写锁还没释放。而事务B是当前读，必须要读最新版本（这里指update时读取k的值，并不是下面的select语句），而且必须加锁，因此就被锁住了，必须等到事务C’释放这个锁，才能继续它的当前读。

这里再来总结一下，事务的可重复读是怎么实现的？

可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。
如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。
而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

• 在**可重复读（RR）**隔离级别下，只需要在 **事务开始时 **创建一致性视图，之后事务里的其他查询都共用这个一致性视图；
• 在**读提交（RC）**隔离级别下，**每个语句执行前 **都会重新算出一个新的视图。

五、“读提交”下的更新逻辑

上面了解了可重复读下的更新逻辑，读提交的逻辑也是相通的。
​

图8：事务B更新逻辑图

这时，事务A的查询语句的视图数组是在执行这个语句的时候创建的，时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但是，在这个时刻：

• (1,3)未提交，不可见；
• (1,2)已提交，而且是在视图创建前提交的，可见。

所以，这时候事务A查询语句返回的是 k=2。
显然地，事务B查询结果 k=3。

参考

极客时间《MySQL实战45讲》