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 日志都连起来,串成一个链表

mysql的undo log在哪里 mysql undolog mvcc_mysql

每次对记录进行更新,都会产生一条 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 操作时访问记录的版本链的过程,这样可以使不同事务的读-写、写-读操作并发控制,从而提高系统性能。