MVCC并发版本控制

本文大部分来自《MySQL是怎样运行的》，这里只是简单总结，用于各位回忆和复习。

版本链

对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列（不知道的快去看《MySQL是怎样运行的》）

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

假设现在有两个事务id 分别为 100 、 200 的事务对这条记录进行 UPDATE 操作，操作流程如下：

每次对记录进行改动，都会记录一条undo日志（不懂的可以理解为一个记录着过去的操作的日志），每条 undo日志也都有一个 roll_pointer 属性（ INSERT 操作对应的 undo日志没有该属性，因为该记录并没有更早的版本），可以将这些 undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：

对该记录每次更新后，都会将旧值放到一条 undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被 roll_pointer 属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id ，这个信息很重要，我们稍后就会用到。

ReadView

我们来引出一下readview是什么东西：

对于使用 READ UNCOMMITTED 隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了

对于使用 SERIALIZABLE 隔离级别的事务来说，则是使用加锁的方式来问记录

但是！！！对于使用 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，mi n_trx_id的值就是1，max_trx_id的值就是4。
creator_trx_id ：表示生成该 ReadView 的事务的事务id 。
- 小贴士：我们前边说过，只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。

有了 ReadView ，这样在访问某条记录时，只需要按照下边4个步骤判断记录的某个版本是否可见：注意，与被访问版本对比的东西都是指（当前最新的ReadView）

如果（被访问版本的） trx_id = creator_trx_id ，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
如果（被访问版本的） trx_id < min_trx_id ，表明生成该版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
如果（被访问版本的） trx_id > max_trx_id ，表明生成该版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
如果（被访问版本的）min_trx_id < trx_id < max_trx_id ，那就需要判断一下 trx_id 属性值是不是在 m_ids 活跃事务列表中。
- 如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，还没提交，该版本不可以被访问。
- 如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

ReadView生成时机

读已提交和可重复读隔离级别最大的区别就是它们生成ReadView的时机不同：

READ COMMITTED —— 每次读取数据前都生成一个ReadView
- 每次select操作都生成一个ReadView，所以每一次查询都在用一个最新生成的ReadView进行上述4步走，所以查出来的应该是最新提交的事务中的最后一个操作（因为一个事务可能有多个增改操作）
REPEATABLE READ —— 在第一次读取数据时生成一个ReadView
- 意味着你在第一次执行select语句之后，不管增删改了多少次，永远拿第一次select生成的ReadView来进行刚刚说的4个步骤判断，所以一直查询的是第一次select语句所查出来的东西。

具体例子这里不过多赘述，还是自行看书。