1、MVCC机制概述

MVCC（Multi-Version Concurrency Control），中文是多版本并发控制，是指在使用**READ COMMITTED**、**REPEATABLE READ**这两种隔离级别的事务在执行SELECT操作时访问记录的版本链的过程，从而在不加锁的前提下使不同事务的读写操作能够并发安全执行，提升系统性能。（读不加锁，读写不冲突）
MVCC机制的核心是在做SELECT操作前会生产一个ReadView，通过这个ReadView可以确认版本链中哪个版本的数据对当前事务可见。READ COMMITTED隔离级别的事务在每次进行SELECT操作前都会成1个ReadView，REPEATABLE READ隔离级别的事务只在第1次进行SELECT操作前生成1个ReadView，之后的查询操作都重复使用这个ReadView。通过ReadView找到符合条件的记录版本（记录版本是由undo日志构建的），其实就像是在生成ReadView的那个时刻做了1次快照，因此利用MVCC机制读取数据又叫快照读，也叫一致性读。

需要注意以下几点：

  • 之前介绍事务时提到过事务并发引起的四种异常场景：脏写、脏读、不可重复读和幻读。对于脏写 MySQL 是通过加锁的方式解决的，MVCC 机制解决的是脏读、不可重复读和幻读；

  • READ COMMITTED隔离级别和REPEATABLE READ隔离级别可以通过MVCC机制保证，SERIALIZABLE隔离级别是通过加锁保证的，READ UNCOMMITTED隔离级别由于什么措施也没做，因此会允许脏读、不可重复和幻读发生。

    2、MVCC版本链的形成

    前面介绍行格式时提到过隐藏列，对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列：

  • trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。注意：只有在对表中的记录做**INSERT**、**DELETE**和**UPDATE**这些修改表中记录的操作时才会给事务分配事务id，且事务id的分配是递增的，一个只读事务的trx_id为0；

  • roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，roll_pointer就相当于一个指针，可以通过它来找到该记录修改前的信息。

如果此时表中只有1条记录，且插入该记录的事务id为80，此时该记录的行格式简化版如下：
MVCC - 图1
假设之后两个事务id分别为100、200的事务对这条记录进行UPDATE操作，操作流程如下：
MVCC - 图2
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志串连起来形成一个链表，如下图：
MVCC - 图3
对该记录的每次更新操作（UPDATE）都会将旧值放到一条undo日志中，即对该记录的一个历史版本，随着更新次数的增多产生的undo日志也增多，所有undo日志被roll_pointer属性连接成一个链表，这个链表就是版本链。关于版本链有以下点需要注意：

  • 版本链是针对某条记录的，即是一条用户记录的不同版本组成的链表；
  • 事务COMMIT之前对记录的修改也会放到undo日志，作为记录的一个历史版本组成版本链；
  • 在版本链中插入undo日志是遵循“头插法”，即每次都是将最近生成的undo日志插入在版本链的链表头部，即版本链头结点对应的记录版本是最新的；

  • 查询版本链时，也是从链表头部遍历，即从最新版本的undo日志记录向老版本的undo日志记录遍历查询。

    3、ReadView（快照）

    3.1 ReadView的形成（重点）

    为了保证READ COMMITTED和REPEATABLE READ隔离级别的事务，尚未提交的记录修改对其他事务不可见，InnoDB提出了ReadView的概念，ReadView主要由以下四部分组成：

  • m_ids：表示在生成ReadView时当前系统中“活跃”的读写事务的事务id列表，注意事务尚未提交时的状态为“活跃”状态；

  • min_trx_id：表示在生成ReadView时当前系统中活跃的（尚未提交的）读写事务中最小的事务id，也就是m_ids中的最小值；
  • max_trx_id：表示生成ReadView时系统中应该分配给下一个（尚未生成的）事务的id值；
  • creator_trx_id：表示生成该ReadView的事务的事务id。

    举例：现在有id为1，2，3这三个事务，之后id为3的事务提交了，一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。

如何根据某个读事务生成的ReadView快照，判断版本链上的某个版本对该查询事务是否可见呢？遵循以下步骤：

  • 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前读事务在访问它自己修改过的记录，所以该版本对当前事务可见；
  • 如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值，表明生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本对当前事务可见；
  • 如果被访问版本的trx_id属性值大于或等于ReadView中的max_trx_id值，表明生成该版本的事务在当前事务生成ReadView后才开启，该版本对当前事务不可见；
  • 如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间，那就需要判断一下trx_id属性值是不是在m_ids列表中，如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本对当前事务不可见；如果不在，说明创建ReadView时生成该版本的事务已经被提交，该版本对当前事务可见。

    面试语录

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

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

3.2 READ COMMITTED

比如现在系统里有两个事务id分别为100、200的事务在执行，记录初始时name值为“刘备”，如下：

  1. # 事务id为100的事务执行如下语句，注意还没有COMMIT，即事务id为100的事务处于“活跃”状态
  2. BEGIN;
  4. UPDATE hero SET name = '关羽' WHERE number = 1;
  6. UPDATE hero SET name = '张飞' WHERE number = 1;
  1. # 事务id为200的事务在对其他表进行操作，目的是让该事务能够分配到一个事务id
  2. BEGIN;
  4. # 更新了一些别的表的记录
  5. ...

此刻，表hero中number为1的记录得到的版本链表如下所示：
MVCC - 图5
假设现在有一个使用READ COMMITTED隔离级别的查询事务开始执行如下语句：

  1. # 使用READ COMMITTED隔离级别的事务，事务id为0
  2. BEGIN;
  4. # SELECT1：Transaction 100、200未提交
  5. # 得到的列name的值为'刘备'
  6. SELECT * FROM hero WHERE number = 1;

这个SELECT1的执行过程如下：

  • 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[100, 200]，min_trx_id为100，max_trx_id为201，creator_trx_id为0；
  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'张飞'，该版本的trx_id值为100，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本；
  • 下一个版本的列name的内容是'关羽'，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本；
  • 下一个版本的列name的内容是'刘备'，该版本的trx_id值为80，小于ReadView中的min_trx_id值100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'刘备'的记录。

之后，我们把事务id为100的事务提交一下，就像这样：

  1. # Transaction 100
  2. BEGIN;
  4. UPDATE hero SET name = '关羽' WHERE number = 1;
  6. UPDATE hero SET name = '张飞' WHERE number = 1;
  8. COMMIT;

然后再到事务id为200的事务中更新一下表hero中number为1的记录，做如下UPDATE操作：

  1. # Transaction 200
  2. BEGIN;
  4. # 更新了一些别的表的记录
  5. ...
  7. UPDATE hero SET name = '赵云' WHERE number = 1;
  9. UPDATE hero SET name = '诸葛亮' WHERE number = 1;

此刻，表hero中number为1的记录的版本链就长这样：
MVCC - 图6
然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个number为1的记录，如下：

  1. # 使用READ COMMITTED隔离级别的事务
  2. BEGIN;
  4. # SELECT1：Transaction 100、200均未提交
  5. SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'
  7. # SELECT2：Transaction 100提交，Transaction 200未提交
  8. SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'张飞'

这个SELECT2的执行过程如下：

  • 在执行SELECT语句时会又会单独生成一个ReadView，该ReadView的m_ids列表的内容就是[200]（事务id为100的那个事务已经提交了，所以再次生成快照时就没有它了），min_trx_id为200，max_trx_id为201，creator_trx_id为0;
  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'诸葛亮'，该版本的trx_id值为200，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是'赵云'，该版本的trx_id值为200，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本。
  • 下一个版本的列name的内容是'张飞'，该版本的trx_id值为100，小于ReadView中的min_trx_id值200，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'张飞'的记录。

从上面过程可以总结出：使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView，且在READ COMMITTED隔离级别下，正是由于每次查询时事务都会生成一个最新的ReadView，这个ReadView太新了，导致每次查询出来的记录可能是不同的（比如SELECT1查询出来的记录是“刘备”，SELECT2查询出来的记录是“张飞”），因此READ COMMITTED隔离级别可以避免脏读，但不能避免不可重复读。

3.3 REPEATABLE READ

比如现在系统里有两个事务id分别为100、200的事务在执行：

  1. # Transaction 100，尚未COMMIT
  2. BEGIN;
  4. UPDATE hero SET name = '关羽' WHERE number = 1;
  6. UPDATE hero SET name = '张飞' WHERE number = 1;
  1. # Transaction 200
  2. BEGIN;
  4. # 更新了一些别的表的记录
  5. ...

此刻，表hero中number为1的记录得到的版本链表如下所示：
MVCC - 图7
现在有一个使用REPEATABLE READ隔离级别的事务开始执行查询操作：

  1. # 使用REPEATABLE READ隔离级别的事务执行select操作
  2. BEGIN;
  4. # SELECT1：Transaction 100、200未提交
  5. SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'

这个SELECT1的执行过程如下：

  • 在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[100, 200]，min_trx_id为100，max_trx_id为201，creator_trx_id为0；
  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'张飞'，该版本的trx_id值为100，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本；
  • 下一个版本的列name的内容是'关羽'，该版本的trx_id值也为100，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本；
  • 下一个版本的列name的内容是'刘备'，该版本的trx_id值为80，小于ReadView中的min_trx_id值100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列name为'刘备'的记录。

之后，我们把事务id为100的事务提交一下，就像这样：

  1. # Transaction 100
  2. BEGIN;
  4. UPDATE hero SET name = '关羽' WHERE number = 1;
  6. UPDATE hero SET name = '张飞' WHERE number = 1;
  8. COMMIT;

然后再到事务id为200的事务中更新一下表hero中number为1的记录：

  1. # Transaction 200
  2. BEGIN;
  4. # 更新了一些别的表的记录
  5. ...
  7. UPDATE hero SET name = '赵云' WHERE number = 1;
  9. UPDATE hero SET name = '诸葛亮' WHERE number = 1;

此刻，表hero中number为1的记录的版本链就长这样：
MVCC - 图8
然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个number为1的记录，如下：

  1. # 使用REPEATABLE READ隔离级别的事务
  2. BEGIN;
  4. # SELECT1：Transaction 100、200均未提交
  5.  # 得到的列name的值为'刘备'
  6. SELECT * FROM hero WHERE number = 1;
  8. # SELECT2：Transaction 100提交，Transaction 200未提交
  9.  # 得到的列name的值仍为'刘备'
  10. SELECT * FROM hero WHERE number = 1;

这个SELECT2的执行过程如下：

  • 因为当前事务的隔离级别为**REPEATABLE READ**，而之前在执行**SELECT1**时已经生成过**ReadView**了，所以此时直接复用之前的**ReadView**，之前的ReadView的m_ids列表的内容就是[100, 200]，min_trx_id为100，max_trx_id为201，creator_trx_id为0;
  • 然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列name的内容是'诸葛亮'，该版本的trx_id值为200，在m_ids列表内，所以不符合可见性要求，根据roll_pointer跳到下一个版本。
  • 下一个版本的列name的内容是'赵云'，该版本的trx_id值为200，也在m_ids列表内，所以也不符合要求，继续跳到下一个版本；
  • 下一个版本的列name的内容是'张飞'，该版本的trx_id值为100，而m_ids列表中是包含值为100的事务id的，所以该版本也不符合要求，同理下一个列name的内容是'关羽'的版本也不符合要求。继续跳到下一个版本；
  • 下一个版本的列name的内容是'关羽'，该版本的trx_id值为100，而m_ids列表中是包含值为100的事务id的，所以该版本也不符合要求，同理下一个列name的内容是'关羽'的版本也不符合要求。继续跳到下一个版本；
  • 下一个版本的列name的内容是'刘备'，该版本的trx_id值为80，小于ReadView中的min_trx_id值100，所以这个版本是符合要求的，最后返回给用户的版本就是这条列c为'刘备'的记录。

从上面过程可以总结出：使用REPEATABLE READ隔离级别的事务在查询时，仅会使用第一次select时生成的ReadView，相比READ COMMITTED隔离级别每次查询时都会生成一个ReadView，REPEATABLE READ隔离级别查询时使用的ReadView版本会没那么新，因此有些最新UPDATE并已经提交的事务对记录做的修改操作对查询事务就会不可见（避免了不可重复读现象的产生），因此REPEATABLE READ隔离级别可以同时避免脏读和不可重复读。

4、MySQL是如何解决幻读的

上面介绍了MySQL针对读事务是如何解决脏读和不可重复读，而InnoDB存储引擎RR事务隔离级别下幻读也不会发生，那是怎么做到的呢？先说结论：在**RR**的隔离级别下，**InnoDB**使用**MVCC**和**next-key locks**解决幻读，**MVCC**解决的是普通读（快照读）的幻读，**next-key locks**解决的是当前读情况下的幻读。

当前读是指加锁（S锁或者X锁）的SELECT、UPDATE和DELETE等语句

4.1 InnoDB解决快照读的幻读

RR事务隔离级别下，对一条记录进行增删改查操作对应如下：

  • **SELECT**：会从最新记录开始遍历版本链，遇到同时满足下面条件的**undo**记录会返回：
    • 版本链中**undo**记录的**trx_id**小于或者等于当前读事务的**id**；（意味着数据在这个事务之前被创建）
    • **undo**记录中的删除版本号为空或者删除版本号大于当前事务**id**。（意味着删除操作在这个事务之后发生）
  • **INSERT**：将当前事务的id保存至undo日志的trx_id；
  • **UPDATE**：会做以下两件事：
    • 新插入一行undo日志，并且新插入的undo日志的trx_id为当前事务的id，新插入的undo记录的值是更新后的；
    • 同时将原undo日志的记录行的删除版本号设置为当前事务的id。
  • **DELETE**：将当前事务的id保存至undo日志对应的删除版本号中。

比如我插入一条记录，事务id 假设是1，那么记录如下：
也就是说，创建版本号就是事务版本号。

id name createversion deleteversion
1 wxt 1

如果我更新的话，事务id假设是2。这里是把 name 更新为 taotao，原来的数据 deleteversion 版本号为这个事务的id，并且新增一条

id name createversion deleteversion
1 wxt 1 2
2 taotao 2

如果我删除的话，假设事务是id=3。

id name createversion deleteversion
3 taotao 2 3

就变成现在这个样子。
关键点来了
现在我读取的话，必须同时满足两个条件的：

  • 读取创建版本小于或等于当前事务版本号，这意味着数据在这个事务之前被创建。
  • 删除版本为空或大于当前事务版本号的记录， 这意味着删除操作在这个事务之后发生。

假设此时数据库的状态：

id name createversion deleteversion
4 a 2
5 b 5

假设事务A的 id=10，执行这条语句update table set name=“hh” where id>3;

id name createversion deleteversion
4 a 2 10
5 b 5 10
4 hh 10
5 hh 10

事务B的 id=11，执行insert into table values(11, uu);

id name createversion deleteversion
4 a 2 10
5 b 5 10
4 hh 10
5 hh 10
11 uu 11

最后事务A（id=10）在此读取，select * from table where id>3；
根据上述的规则，读取创建版本号小于等于当前事务的，那么(4，a),(5，b),(4，hh),(5，hh)。
上面规则的输出作为下面规则的输入的话，删除版本为空或大于当前事务版本号的记录：(4，hh),(5，hh)。
如此读取就没有读取到事务B新插入的那行，解决幻读。

如果事务B是更新 id=4 的数据 name=cc 呢？

id name createversion deleteversion
4 a 2 10
5 b 5 10
4 hh 10 11
5 hh 10
4 cc 11

然后根据select的规则去读取的话，得到的还是(4，hh),(5，hh)。

4.2 InnoDB解决当前读的幻读

所谓当前读，是指加锁（S锁或者X锁）的SELECT、UPDATE和DELETE等语句。在RR事务隔离级别下，InnoDB会使用行锁中的next-key locks来锁住本条记录以及间隙，避免其他事务插入新的记录。
举例：RR事务隔离级别下，一个读事务加了X锁进行如下查询：

  1. SELECT * FROM t WHERE id > 3 FOR UPDATE;

InnoDB存储引擎会将id=3这条记录和id>3的范围间隙加上next-key locks锁，锁住索引中该记录以及记录id>3的范围，避免其他事务修改当前记录或删除当前记录，避免其他事务在next-key locks范围区间插入新的记录，进而避免产生幻影记录。
MySQL锁

面试语录

1. 查询一条记录，基于MVCC，是怎么样的流程？

  1. 获取事务自己的版本号，即事务ID
  2. 获取Read View
  3. 查询得到的数据，然后Read View中的事务版本号进行比较
  4. 如果不符合Read View的可见性规则，即就需要Undo log中历史快照
  5. 最后返回符合规则的数据

InnoDB实现MVCC，是通过Read View + Undo log实现的，Undo log保存了历史快照，Read View可见性规则帮助判断当前版本的数据是否可见。

参考文档

  1. MVCC机制
  2. 面试官：你说熟悉MySQL，那来谈谈InnoDB怎么解决幻读的？
  3. *07 | 事务到底是隔离还是不隔离