MVCC 原理
1. 概念
MVCC 是为了解决事务并发执行过程中所遇到的问题。
2. 版本链
对于使用 InnoDB 存储索引的表来说，它的聚簇索引记录中都包含两个必要的隐藏列，如下
- trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务 id 赋值给 trx_id 隐藏列。
- roll_pointer：每次一个事务对某条聚簇索引记录进行改动时，都会把旧的版本写入 undo 日志中，然后这个隐藏列就相当于一个指针，指向 insert undo，可以通过它来找到该记录修改前的信息，即记录上一个版本。
实际上，insert undo 只在事务回滚时起作用，当事务提交后，该类型的 undo 日志就没用了，它占用的 Undo Log Segment 也会被系统回收，但是虽然真正的 insert undo 日志占用的存储空间被释放了，但是 roll_pointer 的值并不会被清除。
每次对记录进行改动，都会记录一条 undo 日志，每条 undo 日志也都有一个 roll_pointer 属性，可以将这些 undo 日志都连起来，串成一个链表
每次对记录进行更新，都会产生一条 undo 日志，并将最新版本的 roll_pointer 指针指向旧版本，这样就通过 roll_pointer 形成了一条链表，我们把这条链表称之为版本链，版本链的头节点就是当前最新的值。另外，每个版本中还包含生成该版本时对应的事务 id。
3. ReadView
对于使用 read uncommited 隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了；对于使用 serializable 隔离级别的事务来说，InnoDB中规定使用锁的方式来访问记录；对于使用 read commited 和 repeatable read 隔离级别的事务来讲，都必须保证读到了已经提交了的事务修改过的记录。
为了判断版本链中哪个版本是当前事务可见的，InnoDB 中提出了一个 ReadView 的概念，其中包含四个重要内容，如下：
- m_ids：表示在生成 ReadView 时当前系统中活跃的读写事务的事务 id 列表。
- min_trx_id：表示在生成 ReadView 时当前系统中活跃的读写事务中最小的事务 id，也就是 m_ids 中的最小值。
- max_trx_id：表示生成 ReadView 系统中应该分配给下一个事务的 id 值。
- creator_trx_id：表示生成该 ReadView 的事务的事务 id。
在访问某条记录时，判断记录版本是否可见的步骤：
- 如果被访问版本的 trx_id 属性值与 ReadView 中的 creator_trx_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
- 如果被访问版本的 trx_id 属性值小于 ReadView 中的 min_trx_id 值，表明生成版本的事务在当前事务生成 ReadView 前已经被提交，所以该版本可以被当前事务访问。
- 如果被访问版本的 trx_id 属性值在 ReadView 的 min_trx_id 和 max_trx_id 之间，那就需要判断一下 trx_id 属性值是不是在 m_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是很活跃的，该版本不可被访问，如果不在，说明创建 ReadView 时该版本的事务已经被提交，该版本可以被访问。
在 MySQL 中，READ COMMITTED 和 REPEATABLE READ 隔离级别一个大的区别就是它们生成 ReadView 的时机不同。
READ COMMITTED ---- 每次读取数据前都生成一个 ReadView
REPEATABLE READ ---- 在第一次读取数据时生成一个 ReadView
4. MVCC 总结
所谓的 MVCC 指的是在使用 READ COMMITED、REPEATABLE READ 这两种隔离级别的事务在执行普通的 SELECT 操作时访问记录的版本链的过程，这样可以使不同事务的读-写、写-读操作并发控制，从而提高系统性能。