MySQL MVCC精讲

版本链

我们前面说过，对于使用InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列（row_id并不是必要的，我们创建的表中有主键或者非NULL的UNIQUE键时都不会包含row_id列）：

trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。
roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

比方说我们的表hero现在只包含一条记录：
```
 mysql> SELECT * FROM hero;
 +--------+--------+---------+
 | number | name   | country |
 +--------+--------+---------+
 |      1 | 刘备   | 蜀      |
 +--------+--------+---------+
 1 row in set (0.07 sec)
```
假设插入该记录的事务id为80，那么此刻该条记录的示意图如下所示：

ReadView

对于使用 READ UNCOMMITTED 隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了；对于使用 SERIALIZABLE 隔离级别的事务来说，设计InnoDB的大佬规定使用加锁的方式来访问记录（加锁是什么我们后续文章中说）；对于使用 READ COMMITTED 和 REPEATABLE READ 隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：需要判断一下版本链中的哪个版本是当前事务可见的。为此，设计InnoDB的大佬提出了一个ReadView的概念，这个ReadView中主要包含4个比较重要的内容：

m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。
	小贴士：注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。
	比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，
	m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。
creator_trx_id：表示生成该ReadView的事务的事务id。
	小贴士：我们前面说过，只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）
	才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。

有了这个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时生成该版本的事务已经被提交，该版本可以被访问。

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上面的步骤判断可见性，依此类推，直到版本链中的最后一个版本。

在MySQL中，READ COMMITTED 和 REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成 ReadView 的时机不同。我们还是以表hero为例来，假设现在表hero中只有一条由事务id为80的事务插入的一条记录：

mysql> SELECT * FROM hero;
+--------+--------+---------+
| number | name   | country |
+--------+--------+---------+
|      1 | 刘备   | 蜀      |
+--------+--------+---------+
1 row in set (0.07 sec)

接下来看一下 READ COMMITTED 和 REPEATABLE READ 所谓的生成ReadView的时机不同到底不同在哪里。

READ COMMITTED —— 每次读取数据前都生成一个ReadView

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

# Transaction 100
BEGIN;
UPDATE hero SET name = '关羽' WHERE number = 1;
UPDATE hero SET name = '张飞' WHERE number = 1;

# Transaction 200
BEGIN;
# 更新了一些别的表的记录
...

小贴士：再次强调一遍，事务执行过程中，
只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语句），才会被分配一个单独的事务id，这个事务id是递增的。
所以我们才在Transaction 200中更新一些别的表的记录，目的是让它分配事务id。

此刻，表hero中number为1的记录得到的版本链表如下所示：
在这里插入图片描述

假设现在有一个使用 READ COMMITTED 隔离级别的事务开始执行：

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 100、200未提交
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 的事务提交一下，就像这样：

# Transaction 100
BEGIN;
UPDATE hero SET name = '关羽' WHERE number = 1;
UPDATE hero SET name = '张飞' WHERE number = 1;
COMMIT;

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

# Transaction 200
BEGIN;

# 更新了一些别的表的记录
...
UPDATE hero SET name = '赵云' WHERE number = 1;
UPDATE hero SET name = '诸葛亮' WHERE number = 1;

此刻，表hero中number为1的记录的版本链就长这样：
在这里插入图片描述

然后再到刚才使用 READ COMMITTED 隔离级别的事务中继续查找这个 number 为 1 的记录，如下：

# 使用READ COMMITTED隔离级别的事务
BEGIN;

# SELECT1：Transaction 100、200均未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'

# SELECT2：Transaction 100提交，Transaction 200未提交
SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'张飞'

这个 SELECT2 的执行过程如下：( 在执行 SELECT 语句时会又会单独生成一个ReadView)

在执行 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为'张飞'的记录。

以此类推，如果之后事务id为200的记录也提交了，再此在使用READ COMMITTED隔离级别的事务中查询表hero中number值为1的记录时，得到的结果就是’诸葛亮’了，具体流程我们就不分析了。总结一下就是：使用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。

REPEATABLE READ —— 在第一次读取数据时生成一个ReadView

对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。大家可以类推下这个select 过程。

从上面的描述中我们可以看出来，所谓的MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程，这样子可以使不同事务的读-写、写-读操作并发执行，从而提升系统性能。READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是：生成ReadView的时机不同，READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView，而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView就好了。

PURGE

大家有没有发现两件事儿：

我们说 insert undo 在事务提交之后就可以被释放掉了，而 update undo 由于还需要支持MVCC，不能立即删除掉
为了支持MVCC，对于delete mark操作来说，仅仅是在记录上打一个删除标记，并没有真正将它删除掉。

update undo 日志和被标记为删除的记录只是为了支持 MVCC 而存在的,只要系统中最早产生的那个 ReadView 不再访问它们,它们的使命就结束了，就可以丢进历史的垃圾堆里了。一个 ReadView 在什么时候才肯定不会访问某个事务执行过程中产生的 undo 日志呢? 其实,只要我们能保证生成 ReadView 时某个事务已经提交,那么该 ReadView 肯定就不需要访问该事务运行过程中产生的 undo 日志了 (因为该事务所改动的记录的最新版本均对该 ReadView 可见)。

设计 InnoDB 的大叔为此做了两件事。

在一个事务提交时,会为这个事务生成一个名为事务no的值,该值用来表示事务提交的顺序,先提交的事务的事务 no
值小, 后提交的事务的事务no值大

 别忘了在一组 undo 日志中对应的 Undo Log Header 部分有一个名为 TRX UNDO TRXNO的属性。
 当事务提交时,就把该事务对应的事务 no 值填到这个属性中。
 因为事务 no 代表着各个事务提交的顺序,而 History 链表又是按照事务提交的顺序来排列各组 undo 日志的，
 所以 history 链表中的各组 undo 日志也是按照对应的事务 no 来排序的。

一个 ReadView 结构除了包含前面唠叨过的几个属性之外,还会包含一个事务 no 的属性。在生成一个 ReadView时，会把比当前系统中最大的事务 no 值还大1的值赋给这个属性。

设计 InnoDB 的大叔还把当前系统中所有的 ReadView 按照创建时间连成了一个链表。当执行 purge 操作时 (这个 purge 操作是在专门的后台线程中执行的),就把系统中最早生成的ReadView 给取出来。如果当前系统中不存在 ReadView,就现场创建一个 (新创建的这Readiew 的事务 no 值肯定比当前已经提交的事务的事务 no 值大)。然后从各个回滚段的History 链表中取出事务 no 值较小的各组 undo 日志。如果一组 undo 日志的事务 no 值小于当前系统最早生成的 ReadView 的事务 no 属性值,就意味着该组 undo 日志没有用了，就会从History 链表中移除,并且释放掉它们占用的存储空间。如果该组 undo 日志包含因 delete mark 操作而产生的 undo 日志 (TRX UNDO DEL_MARKS 属性值为 1),那么也需要将对应的标记为删除的记录给彻底删除。

这里有一点需要注意，当前系统中最早生成的 ReadView 决定了 purge 操作中可以清理哪些pdate undo 日志以及打了删除标记的记录。如果某个事务使用 REPEATABLE READ 隔离级别,那么该事务会一直复用最初产生的 ReadView。假如这个事务运行了很久,一直没有提交,那么最早生成的 ReadView 会一直不释放,系统中的 update undo 日志和打了删除标记的记录就会越来越多，表空间对应的文件也会越来越大,一条记录的版本链将会越来越长,从而影响系统性能。