MVCC原理

1. 版本链

对于使用 InnoDB 存储引擎的表来说，它的聚簇索引记录中有3个隐藏列，其中一个就是roll_pointer，每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo 日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

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

2. ReadView

2.1 ReadView内容

ReadView使用来判断一下版本链中的哪个版本是当前事务可见的这个问题。ReadView由事务生成，会保存生成时数据的状态，用来判断。其内容如下：

• 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。

2.2 ReadView判断流程

有了这个 ReadView ，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见，trx_id 为该记录的事务 id：

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

3. 生成ReadView的时机

其中 READ COMMITTED 和 REPEATABLE READ 生成时机不同。

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

在一个事务中每次 select 可能的数据不一样，因为生成的 ReadView 每次都会重新生成。

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

在一个事务中每次 select 可能的一样，因为生成的 ReadView 每次都是一样的。

4. MVCC小结

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