多版本并发控制MVCC

什么是MVCC

• MVCC （Multiversion Concurrency Control），多版本并发控制。顾名思义，MVCC 是通过数据行的多个版本管理来实现数据库的并发控制 。这项技术使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。
• MVCC没有正式的标准，在不同数据库中可以有不同的实现。
• MySQL中只有InnoDB存储引擎支持MVCC。

快照读和当前读

• MVCC在MySQL InnoDB中的实现主要是为了提高数据库并发性能，用更好的方式去处理读-写冲突，做到即使有读写冲突时，也能做到 不加锁 ， 非阻塞并发读 ，而这个读指的就是快照读 , 而非当前读 。当前读实际上是一种加锁的操作，是悲观锁的实现。而MVCC本质是采用乐观锁思想的一种方式。

快照读

• 又称为一致性读，读取的是快照数据。不加锁的简单的SELECT都属于快照读，也即不加锁的非阻塞读。
• 当然，快照读是建立在隔离级别不是串行化的基础之上的，串行化隔离级别下的快照度都会退化成当前读。
• 之所以出现快照读的情况，是基于提高并发性能的考虑，快照读的实现是基于MVCC，它在很多情况下，避免了加锁操作，降低了开销。
• 既然是基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

当前读

• 当前读读取的是记录的最新版本，读取时还需要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。
• 加锁的Select或者对数据进行增删改都会进行当前读

  

复习

• MVCC 的实现依赖于：隐藏字段、Undo Log、Read View。

隔离级别

• 在MySQL下，默认隔离级别是可重复读（REPEATABLE-READ），可以解决**脏读**和**不可重复读**以及**幻读**的问题。
• 但是MySQL解决幻读并不是串行化的方式。而是MVCC解决的

  

隐藏字段

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

    

Undo Log版本链

• 每次对记录进行修改，都会记录一条Undo Log，每条Undo Log也都有一个 **roll_pointer**属性（ INSERT 操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些 Undo Log都连起来，串成一个链表：

  

  记录之间通过roll_pointer进行连接，版本链的头节点就是当前记录的最新值。

  同时，每个版本中还记录着生成该版本时对应的事务id。

MVCC实现原理

• MVCC 的实现依赖于：隐藏字段、Undo Log、Read View。
• 首先明确，针对的是READ COMMITTED 和 REPEATABLE READ 隔离级别的事务，保证读取到的是已经提交了的事务修改过的记录。

什么是ReadView

• 在MVCC机制中，多个事务对同一行记录进行更新会产生多个历史快照，这些历史快照保存在Undo Log中。如果一个事务想要查询这个行记录，那么在多个版本中应该读取哪一个呢？此时就需要使用ReadView了。他帮我们解决了行的可见性问题。
• 解决的核心问题是判断一下版本链中的哪个版本是当前事务可见的
• Read View 保存了当前事务开启时所有活跃的事务列表。换个角度，可以理解为: Read View 保存了不应该让这个事务看到的其他事务 ID 列表。
• RR隔离级别（除了Gap锁之外）和RC隔离级别的差别是创建snapshot时机不同。 RR隔离级别是在事务开始时刻，确切地说是第一个读操作创建Read view的；RC隔离级别是在语句开始时刻创建Read view的。（每一次Select都会生成）

ReadView数据结构中的重要字段

1. creator_trx_id：创建这个 Read View 的事务 ID。注意：只有对增删改的事务才会分配事务ID，对于只读事务，事务ID默认为0。
2. trx_ids ：表示在生成ReadView时当前系统中活跃的读写事务的事务ID列表 。
3. up_limit_id ：活跃的事务中最小的事务 ID。
4. low_limit_id：表示生成ReadView时系统中应该分配给下一个事务的 id 值。low_limit_id 是系统最大的事务id值+1，这里要注意是系统中的事务id，需要区别于正在活跃的事务ID。

ReadView如何控制版本可见？

• 当我们想要访问某个记录时，通过Read View就可以判断记录的某个版本对当前事务是否可见。
  • 如果事务T访问的记录的trx_id与事务T生成的ReadView中的creator_trx_id相等，表示事务T正在访问自己修改过的记录，所以**trx_id**版本对事务T**可见**。
  • 如果事务T访问的记录的trx_id<事务T生成的ReadView中的up_limit_id(活跃事务的最小ID)相等，表示对**trx_id**进行修改的事务已经提交了，事务T在此之后才创建，所以**trx_id**版本对事务T**可见**。
  • 如果事务T访问的记录的trx_id≥事务T生成的ReadView中的low_limit_id(系统中最大的事务ID)，表示对**trx_id**进行修改的事务在事务T在此之后才创建，所以**trx_id**版本对事务T**不可见**。
  • 如果事务T访问的记录的trx_id介于事务T生成的ReadView的**up_limit_id**(≥)和**low_limit_id**(＜)之间，需要根据被访问记录的**trx_id**是不是在ReadView的**trx_ids**中
    • 如果在，说明事务T创建ReadView的时候，对**trx_id**进行修改的事务还在活跃中，所以该版本对事务T不可见。
    • 如果不在，说明事务T创建ReadView的时候，对**trx_id**进行修改的事务已经被提交，所以该版本对事务T可见。

MVCC整体流程

• 当一个事务中有查询语句时，MVCC如何决定选择读取的版本？
  1. 首先获取事务自己的版本号，也就是事务 ID；
  2. 获取 ReadView；
  3. 查询得到的数据，然后与 ReadView 中的事务版本号进行比较；
  4. 如果不符合 ReadView 规则，就需要从 Undo Log 中获取历史快照；
  5. 最后返回符合规则的数据。
• 在可重复读（REPEATABLE-READ）隔离级别下，一个事务只在第一次 SELECT 的时候会生成一次 Read View，而后面所有的 SELECT 都会复用这个 Read View。由于都是同一个ReadView，所以每次读取的数据都是一样的。
• 在读已提交隔离级别（Read Committed）下，一个事务中的每一次 SELECT 查询都会重新生成一次Read View。此时同样的查询语句都会重新获取一次 Read View，这时如果 Read View 不同，就可能产生不可重复读或者幻读的情况。

案例说明

RC隔离级别下

• 对于两个事务，事务ID分别为10和20

  初始记录

  

  

  因为，只有增删改才会分配事务ID，所以为事务20执行一些增删改操作，使其获取事务ID

  事务10执行后（未提交）的id为1的Undo Log版本链如下

  

  此时开启一个事务去读取id为1数据，读取的记录是”张三”，过程如下

  

  首先，执行SELECT之前会先生成一个ReadView。此时ReadView中的数据如下，

  由于是只读事务，所以，creator_trx_id为0

  活跃的事务列表trx_ids为[10,20]，

  up_limit_id活跃的事务中最小的事务ID为10

  low_limit_id最大的事务ID为21

  首先，读取版本链的头节点，trx_id为10，在ReadView的up_limit_id和low_limit_id范围内，并且还在ReadView的trx_ids中，说明修改记录的事务还未提交，所以trx_id为10的记录不可见

  然后读取下一个版本记录trx_id同样为10，不可见

  然后读取下一个版本记录trx_id为8，由于trx_id为8<up_limit_id，说明修改这条记录的事务已经提交，所以对于当前ReadView是可见的。所以读出的记录就是”张三” 然后事务10提交，事务20修改并且还未提交

  

  此时的版本链如下

  

  再次使用刚才的读事务进行id为1的数据读取

  

  由于是RC隔离级别，所以会重新生成一个ReadView

  此时ReadView中的数据如下

  由于是只读事务，所以，creator_trx_id为0

  活跃的事务列表trx_ids为[20]，

  up_limit_id活跃的事务中最小的事务ID为20

  low_limit_id最大的事务ID为21

  首先，读取版本链头节点中的trx_id为20的记录，由于20介于up_limit_id和low_limit_id之间，这里是等于up_limit_id，然后判断trx_id是否在trx_ids中，结果是，所以当前记录trx_id为20对当前ReadView不可见

  读取下一个记录，trx_id为20，同样不可见

  读取下一条记录，trx_id为10，10<up_limit_id，说明对此记录修改的事务已经提交，所以对当前ReadView可见，读取的记录就是“王五” 通过以上分析，可以发现RC模式下由于每次Select都会使用新的ReadView，所以是存在不可重复读和幻读问题的。

RR隔离级别下

• 对于两个事务，事务ID分别为10和20

  初始记录

  

  

  因为，只有增删改才会分配事务ID，所以为事务20执行一些增删改操作，使其获取事务ID

  事务10执行后（未提交）的id为1的Undo Log版本链如下

  

  此时开启一个事务去读取id为1数据，读取的记录是”张三”，过程如下

  

  首先，执行SELECT之前会先生成一个ReadView。此时ReadView中的数据如下，

  由于是只读事务，所以，creator_trx_id为0

  活跃的事务列表trx_ids为[10,20]，

  up_limit_id活跃的事务中最小的事务ID为10

  low_limit_id最大的事务ID为21

  首先，读取版本链的头节点，trx_id为10，在ReadView的up_limit_id和low_limit_id范围内，并且还在ReadView的trx_ids中，说明修改记录的事务还未提交，所以trx_id为10的记录不可见

  然后读取下一个版本记录trx_id同样为10，不可见

  然后读取下一个版本记录trx_id为8，由于trx_id为8<up_limit_id，说明修改这条记录的事务已经提交，所以对于当前ReadView是可见的。所以读出的记录就是”张三” 然后事务10提交，事务20修改并且还未提交

  

  此时的版本链如下

  

  再次使用刚才的读事务进行id为1的数据读取

  

  由于是RR隔离级别，所以直接复用第一次Select生成的ReadView

  也就是在RR隔离级别下，同一个事务中，ReadView是同一个。

  所以其中的数据也是一样的。

  读取版本链的过程和上面一样 由于在RR隔离级别下，同一个事务中ReadView是同一个，在生成的时候就已经记录了系统中的事务信息，所以，每次读取就和第一次读取的数据一样，这就解决了不可重复读和幻读的问题。

总结

• MVCC 在 READ COMMITTD 、 REPEATABLE READ 这两种隔离级别的事务在执行快照读操作时访问记录的版本链的过程。
• 核心点在于 ReadView 的原理， READ COMMITTD 、 REPEATABLE READ 这两个隔离级别的一个很大不同就是生成ReadView的时机不同：
  • READ COMMITTD 在每一次进行普通SELECT操作前都会生成一个ReadView
  • REPEATABLE READ 只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都重复使用这个ReadView