【mysql】事务隔离的原理剖析

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view（又称一致性视图），之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。

事务的启动时机与一致性视图的创建时机

（1）第一种启动方式：begin/start transaction + 执行第一个操作 InnoDB 表的语句（增删改查均可）
begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作 InnoDB 表的语句，事务才真正启动。而一致性视图是在执行第一个快照读（select）语句时创建的；

（2）第二种启动方式： start transaction with consistent snapshot 这个命令
执行完start transaction with consistent snapshot 事务马上开启，而一致性视图也会在命令执行时创建

Mysql的两种视图概念

一个是 view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是 create view … ，而它的查询方法与表一样。view视图有物理结构
另一个是 InnoDB 在实现 MVCC 时用到的一致性读视图，即 consistent read view，用于支持 RC（Read Committed，读提交）和 RR（Repeatable Read，可重复读）隔离级别的实现。一致性视图没有物理结构，一致性视图通过高低水位，数据版本号，undo log来进行判断数据可见不可见

“快照”在 MVCC 里的工作原理

“可重复读”隔离级别下，事务在启动时“拍了个快照”。注意，这个快照是基于整库的。
“读已提交”隔离级别下，事务在启动时“拍了个快照”。但这个视图是在每个 SQL 语句开始执行的时候创建的。

事务ID概念
InnoDB 里面每个事务有一个唯一的事务 ID，叫作 transaction id。它是在事务启动时（不一定是创建的时候，如begin/start transaction，是没有申请事务id的）向 InnoDB 的事务系统申请的，是按申请顺序严格递增的。

同一记录多版本概念
数据表中的一行记录，其实可能有多个版本 (row)，每个版本有自己的 row trx_id。一个记录被多个事务连续更新后的状态如下：

图2

图中虚线框里是同一行数据的 4 个版本，当前最新版本是 V4，k 的值是 22，它是被 transaction id 为 25 的事务更新的，因此它的 row trx_id 也是 25。
图 2 中的三个虚线箭头，就是 undo log；而 V1、V2、V3 并不是物理上真实存在的，而是每次需要的时候根据当前版本和 undo log 计算出来的。比如，需要 V2 的时候，就是通过 V4 依次执行 U3、U2 算出来。

InnoDB 定义快照原理

在可重复读隔离级别下，事务启动的时候，能够看到所有已经提交的事务结果。但是之后，这个事务执行期间，其他事务的更新对它不可见，需要找到可见的版本（或者事务自己更新的版本）。

事务可见性实现规则

在实现上， InnoDB 为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务 ID（实现上不包括当前启动的事务）。“活跃”指的就是，启动了但还没提交。
数组里面事务 ID 的最小值记为低水位，当前系统里面已经创建过的事务 ID的最大值加 1 记为高水位。(PS:如在事务A启动瞬间，再计算高水位，创建数组。高水位不一定是事务A的id+1)。举例如下：

#情况1
假设 ：目前正在活跃事务id为99
1. 事务A启动，申请到trx_id 100
4. 计算高水位（等于99+1），事务A创建视图数组 [99] （实现上,事务启动瞬间，视图数组不包含自己的事务id，文章原作者这里[99，100] ，不重要，因为事务A自己的更新总是可见）

#情况2
假设 ：目前正在活跃事务id为99
1. 事务A启动，申请到trx_id   100
2. 事务B启动，申请到 trx_id  101
3. 事务C启动，申请到 trx_id  102
4. 计算高水位（等于102+1），事务A创建视图数组 [99，100，101，102]

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

如果落在绿色部分（低于低水位），表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；
如果落在红色部分（高于高水位），表示这个版本是由将来启动的事务生成的，是肯定不可见的；
如果落在黄色部分，那就包括两种情况： a.   若 row trx_id 在数组中，表示这个版本是由还没提交的事务生成的，不可见；
                               b.   若 row trx_id 不在数组中，表示这个版本是已经提交了的事务生成的，可见。

事务可见性规则总结

一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：
版本未提交，不可见；
版本已提交，但是是在视图创建后提交的，不可见；
版本已提交，而且是在视图创建前提交的，可见。

事务查询逻辑（可重复读隔离级别）

事务A查询字段K，从当前版本查，再利用数据可见性规则，直到查到可见版本。这样执行下来，虽然期间这一行数据被修改过，但是事务 A 不论在什么时候查询，看到这行数据的结果都是一致的，所以我们称之为一致性读。

事务更新逻辑（可重复读隔离级别）

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。
如事务 B 的 update 语句是当前读，另外，select 语句如果加锁，也是当前读。

mysql> select k from t where id=1 lock in share mode;    //加了读锁（S 锁，共享锁）
mysql> select k from t where id=1 for update;            //写锁（X 锁，排他锁）

图3

图4

图3和图4区别，事务C立马提交，而事务 C’，更新后并没有马上提交。在它提交前，事务 B 的更新语句先发起了。前面说过了，虽然事务 C’还没提交，但是 (1,2) 这个版本也已经生成了，并且是当前的最新版本。

“两阶段锁协议”就要上场了。事务 C’没提交，也就是说 (1,2) 这个版本上的写锁还没释放。而事务 B 是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到事务 C’释放这个锁，才能继续它的当前读。

到这里，我们把一致性读、当前读和行锁就串起来了。

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

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

这里需要说明一下，“start transaction with consistent snapshot; ”的意思是从这个语句开始，创建一个持续整个事务的一致性快照。所以，在读提交隔离级别下，这个用法就没意义了，等效于普通的 start transaction

下面是读提交时的状态图，可以看到这两个查询语句的创建视图数组的时机发生了变化，就是图中的 read view 框。（注意：这里，我们用的还是事务 C 的逻辑直接提交，而不是事务 C’）

这时，事务 A 的查询语句的视图数组是在执行这个语句的时候创建的，时序上 (1,2)、(1,3) 的生成时间都在创建这个视图数组的时刻之前。但是，在这个时刻：
(1,3) 还没提交，属于情况 1（情况123，见事务可见性规则总结），不可见；
(1,2) 提交了，属于情况 3，可见。
所以，这时候事务 A 查询语句返回的是 k=2。显然地，事务 B 查询结果 k=3。

总结

小结InnoDB 的行数据有多个版本，每个数据版本有自己的 row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。

• 对于可重复读，查询只承认在事务启动前就已经提交完成的数据；
• 对于读提交，查询只承认在语句启动前就已经提交完成的数据；
  而当前读，总是读取已经提交完成的最新版本。

你也可以想一下，为什么表结构不支持“可重复读”？这是因为表结构没有对应的行数据，也没有 row trx_id，因此只能遵循当前读的逻辑。

当然，MySQL 8.0 已经可以把表结构放在 InnoDB 字典里了，也许以后会支持表结构的可重复读。