• 1、MVCC机制概述
• 2、MVCC版本链的形成
• 3、ReadView（快照）
  • 3.1 ReadView的形成
  • 3.2 READ COMMITTED
  • 3.3 REPEATABLE READ
• 4、MySQL是如何解决幻读的
  • 4.1 InnoDB解决快照读的幻读
  • 4.2 InnoDB解决当前读的幻读
• 参考

1、MVCC机制概述

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

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

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

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

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

  3、ReadView（快照）

  3.1 ReadView的形成

  对于使用READ UNCOMMITTED隔离级别的事务来说，由于允许读到未提交事务修改过的记录（脏读），因此直接读取版本链的最新版本就可以了；对于使用SERIALIZABLE隔离级别的事务来说，需要用加锁的方式保证事务的串行化执行；对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证事务1已经修改了记录但是尚未提交，事务2不能直接读取到最新版本的记录，即事务1中尚未提交的记录修改对事务2是不可见的。为了保证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机制概述时提到，读事务在生成ReadView时，在READ COMMITTED和REPEATABLE READ隔离级别下生成的时机是不同的，通过READ COMMITTD隔离级别的事务在每次进行SELECT操作前都会成1个ReadView，REPEATABLE READ隔离级别的事务只在第1次进行SELECT操作前生成1个ReadView，之后的查询操作都重复使用这个ReadView，下面结合例子具体介绍。

3.2 READ COMMITTED

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

# 事务id为100的事务执行如下语句，注意还没有COMMIT，即事务id为100的事务处于“活跃”状态
BEGIN;
UPDATE hero SET name = '关羽' WHERE number = 1;
UPDATE hero SET name = '张飞' WHERE number = 1;

# 事务id为200的事务在对其他表进行操作，目的是让该事务能够分配到一个事务id
BEGIN;
# 更新了一些别的表的记录
...

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

update table set name="hh" where id > 3;

insert into table values(9, uu);

select * from table where id > 3;

SELECT * FROM t WHERE id > 3 FOR UPDATE;