你是否对MySQL数据库中的事务已经有所了解呢？

你是否对 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：

事务 B：

事务 C：

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

 

事务A：num=1

事务B：num=3

 

为什么是这样输出？

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

1、MVCC

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

多版本控制: 指的是一种提高并发的技术。最早的数据库系统，只有读读之间可以并发，读写，写读，写写都要阻塞。引入多版本之后，只有写写之间相互阻塞，其他三种操作都可以并行，这样大幅度提高了 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 的描述：

直译：

一个读操作使用基于某个时刻的快照信息来显示查询结果，而不考虑同时运行的其他事务所执行的更改。如果查询到的数据被其他事务所更改，则根据 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）

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 操作都是先读后写，这个读属于锁定读（当前读）。

审核编辑：刘清