MySQL底层之MVCC、回滚段、一致性读、锁定读

2020-09-10

你是否对MySQL数据库中的事务已经有所了解？看下面这张图，按照1～6的顺序依次执行，在RR隔离级别下，事务A和事务B各自输出的num值是多少吗？

我们预先创建好这样一张表并初始化一条数据：

CREATE TABLE `test1`  (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键Id',
  `num` int(11) NULL COMMENT '数量',
  PRIMARY KEY (`id`)
) ENGINE = InnoDB;
insert into test1(id, num) values (1, 1);

然后开始按上图的顺序执行各个事务，这需要我们打开3个操作窗口来分别执行A、B、C三个事务：

事务A：

事务A

事务B：

事务B

事务C：

事务C

按照上图的执行顺序执行commit，其中事务C是自动提交事务的，不需要我们显示的commit，事务A、B的输出结果如下：

事务A：num=1
事务B：num=3

为什么是这样输出？

它的背后其实是：MVCC（多版本并发控制）、consistent read（一致性读）、locking reads（锁定读）等MySQL数据库底层知识。

1、MVCC

MySQL数据库官网文档是这样来描述MVCC的：

官网链接：https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html

淘宝的数据库内核月报中有提到（文末有文章链接）：

多版本控制: 指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了InnoDB的并发度。在内部实现中，与Postgres在数据行上实现多版本不同，InnoDB是在undolog中实现的，通过undolog可以找回数据的历史版本。找回的数据历史版本可以提供给用户读(按照隔离级别的定义，有些读请求只能看到比较老的数据版本)，也可以在回滚的时候覆盖数据页上的数据。在InnoDB内部中，会记录一个全局的活跃读写事务数组，其主要用来判断事务的可见性。

目前来看MVCC的实现依赖于：

隐藏字段（DB_TRX_ID、DB_ROLL_PTR）
回滚日志（undo log）
一致性读（consistent read）

你也可以这样去理解MVCC：一个事务对数据进行更新操作时候，先把旧的数据放到一个单独的地方（回滚段），其他事务读取数据时候，根据DB_TRX_ID、DB_ROLL_PTR计算出undo log链中当前版本的数据。

2、一致性读（consistent read）

继续看官方文档对consistent read的描述：

官网链接：https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_consistent_read

直译：

一个读操作使用基于某个时刻的快照信息来显示查询结果，而不考虑同时运行的其他事务所执行的更改。如果查询到的数据被其他事务所更改，则根据undo log中的内容来重建原始数据。这种技术避免了一些通过强制事务等待其他事务完成而降低并发性的锁定问题。

在RR级别下，首次读操作被执行时候创建一致性读视图ReadView，事务的后续读都基于该视图的数据；
在RC级别下，每一次读操作都会创建一个最新的ReadView，因此每次select读都可以获取到当前已提交事务的最新数据；

“一致性读”是InnoDB引擎在RC和RR隔离级别下处理select语句的默认模式。因为一个“一致性读”是不需要对它访问的表设置任何的锁，当对表执行“一致性读”时候，其他会话可以自由的修改这些表。

另外：

读未提交（read uncommitted）、串行化（serializable）是不需要依赖MVCC的，读未提交直接每次都读取当前数据的最新值即可。而serializable是直接采用加锁的操作让所有的事务都串行化执行，牺牲了并发能力。

一致性读的实现方式：

每个事务启动的瞬间，都会构建一个数组（m_ids），用来记录目前所有“活跃事务”（事务启动了，但是还没提交）的 ID；
数组中的最小事务ID为低水位;
数组中的最大事务ID+1为高水位；
数据版本可见性规则：当前数据某个版本是否可见，取决于当前数据的DB_TRX_ID以及这个一致性视图数组中记录的事务ID做对比来判断：低水位以前的数据版本可见，高水位以后的数据版本不可见，低水位和高水位之间得查看当前数据版本的DB_TRX_ID是否存在数组中，若存在意味着事务未提交，不可见，若不存在意味着事务已提交，可见。

那按照一致性读的理解，事务B已经创建了自己的快照数据了，它的输出应该是num = 2呀，为什么会是num=3？

可是如果不是num=3，那么已经提交的事务C的操作不就丢失了吗？（产生丢失更新问题）

这里又涉及到一个知识点：

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

3、当前读（current reads）

也叫做锁定读（locking reads）

官方文档：https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html

InnoDB引擎支持两种方式的锁定读以提供额外的安全性（MySQL 5.7版本）：

# 读锁（S 锁，共享锁）
SELECT ... LOCK IN SHARE MODE;
# 写锁（X 锁，排他锁）
SELECT ... FOR UPDATE;

锁定读会在被读取的数据上加一把共享锁，其他事务可以读取记录，但是不可以修改记录，直到当前事务提交。

锁定读验证：

为什么要有锁定读？

如果你在一个事务中先查询了一个数据，然后插入或者更新相关的数据，这个时候来了一个事务B同时更新或者删除你要查询的记录，就会出现幻读问题了。

这也是为什么MVCC不能完全解决幻读的问题，而是需要MVCC+行锁+间隙锁（next-key lock）的方式。

4、事务A、B、C的执行流程

继续看开头的第一张图：

start transaction with consistent snapshot;

这条SQL语句可以立即启动事务，创建当前事务的一致性读快照。效果等同于start transaction然后马上执行select语句。

我们接下来看看文章开头的三个事务对数据行的修改流程，按照步骤1～6的操作如下：

如果大家细致的查看上图的三个事务的穿插执行流程，可以发现，A、B、C三个事务无论是commit还是rollback，都是可以最终得到正确的数据。

这就是InnoDB引擎下的多版本并发控制（MVCC）的实现原理。

总结以下几个关键点：

每一个事务都会创建一个数据快照，快照创建的时机根据隔离级别的不同有所区别；
每一个事务都会生成一个全局唯一的DB_TRX_ID，用于标记当前版本；
DB_ROLL_PTR是回滚指针的意思，结合DB_TRX_ID来最终确定我要拿到的数据；
DB_TRX_ID、DB_ROLL_PTR、undo log这三个值来控制数据的版本；
update、delete操作都是先读后写，这个读属于锁定读（当前读）。

5、巨人的肩膀

《MySQL实战45讲》
《高性能MySQL 第二版》
MySQL官网：https://dev.mysql.com/doc/refman/8.0/en/innodb-multi-versioning.html
淘宝数据库内核月报－ 2017 / 12：http://mysql.taobao.org/monthly/2017/12/01/

最后，感谢大家能够看到这里，也许这篇文章并不能让你能够彻底了解MVCC的工作原理，看完之后可能还会有很多疑问，欢迎大家在评论区多多讨论，充分交流，共同学习。