MVCC 底层实现原理

概述

MVCC(Multi-Version Concurrency Control) ，叫做基于多版本的并发控制协议。

MVCC 是乐观锁的一种实现方式，它在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

读已提交、可重复读基于此来实现

事务并发出现的问题

脏读

当一个事务读取到另一个事务未提交的数据，被称为脏读

1、在事务A执⾏过程中，事务A对数据资源进⾏了修改，事务B读取了事务A修改后的数据。
2、由于某些原因，事务A并没有完成提交，发⽣了RollBack操作，则事务B读取的数据就是脏数据。
这种读取到另⼀个事务未提交的数据的现象就是脏读(Dirty Read)。

不可重复读

当事务内相同的记录被检索两次，且两次得到的结果不同时，此现象称为不可重复读

事务B读取了两次数据资源，在这两次读取的过程中事务A修改了数据，导致事务B在这两次读取出来的
数据不⼀致。

幻读

在事务执行过程中，另一个事务将新记录添加到正在读取的事务中时，会发生幻读。

事务B前后两次读取同⼀个范围的数据，在事务B两次读取的过程中事务A新增了数据，导致事务B后⼀
次读取到前⼀次查询没有看到的行。

幻读和不可重复读有些类似，但是幻读重点强调了读取到了之前读取没有获取到的记录。

事务隔离级别

那么为啥设置不同的隔离级别，就可以相应的规避 脏读、不可重复读、幻读呢？

• 读未提交
  对于使用READ UNCOMMITTED隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了（所以就会出现脏读、不可重复读、幻读）

• 可串行化
  对于使用SERIALIZABLE隔离级别的事务来说，InnoDB使用加锁的方式来访问记录（也就是所有的事务都是串行的，当然不会出现脏读、不可重复读、幻读）

上面两个很好理解，而读已提交与可重复度是怎么实现的呢？

接下来就要介绍 MVCC …

MVCC 底层实现原理

MVCC实现原理主要是依赖记录中的隐式字段，undo日志，Read View 来实现

隐式字段

表中每行记录除了我们自定义的字段外，还有数据库隐式定义的

DB_TRX_ID, 最近修改（修改/插入）的事务ID
DB_ROLL_PTR, 回滚指针，用于配合undo日志，指向这条记录的上一个版本
DB_ROW_ID 隐含的自增 ID（隐藏主键），如果数据表没有主键，InnoDB 会自动以DB_ROW_ID
产生一个聚簇索引

等字段

undo 日志

数据库事务四大特性中有一个是原子性 ，具体来说就是原子性是指对数据库的一系列操作，要么全部成功，要么全部失败，不可能出现部分成功的情况。实际上， 原子性底层就是通过 undo log 实现的。

undo log主要记录了数据的逻辑变化，比如一条 INSERT 语句，对应一条INSERT 的 undo log ，对于每个 UPDATE 语句，对应一条相反的 UPDATE 的 undo log ，这样在发生错误时，就能回滚到事务之前的数据状态。同时， undo log 也是 **MVCC(多版本并发控制)**实现的关键。

不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，也就是版本链。

对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链

版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为，那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。

Read View

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，min_trx_id的值就是1，max_trx_id的值就是4。
• creator_trx_id：表示生成该ReadView的事务的事务id。

ReadView生成规则

• READ COMMITTED(读已提交)
  在一个事务中，每次查询都会生成一个新的ReadView
• REPEATABLE READ(可重复读)
  在一个事务中只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了

ReadView校验规则

1. 如果当前被访问记录的trx_id属性值与ReadView中的creator_trx_id值相同，说明当前事务修改的记录就是在当前事务下操作的，那当然是对我们可见的了，因此可以修改这条记录

2. 如果当前被访问记录的trx_id属性值小于ReadView中min_trx_id值，说明(生成该版本的事务在该事务生成readView之间已经提交)即当前事务在开启的时候，这条记录最近一次被其他事务操作的事务已经提交了，所以对这条记录对我们来说也是可以见，可以修改

3. 如果当前被访问记录的trx_id属性值大于或者等于ReadView中max_trx_id值，说明(生成该版本的事务在当前事务生成readView之后才开启)即：我们开启事务未修改该记录之前，已经有另外一个事务开启，并且正在修改该事务了，因此，这条记录对我们来说依然是不可见的，我们不能修改

4. 如果当前被访问记录的trx_id属性值介于ReadView中 min_trx_id 和 max_trx_id 之间的话，那么此时就需要分情况讨论了

   此时我们应该分析该trx_id是否在 m_ids 中

   • 如果在，说明(创建ReadView时，生成该版本的事务还处于活跃状态)即：当前已经有其它的事务正在修改该条记录，并且还未提交，此时这条记录对我们不可见

   • 如果不在，说明((创建ReadView时，生成该版本的事务已经提交)即：此时没有事务操作该条记录，我们可以修改该条记录

在这种机制下，每次查询数据会去判断当前记录的版本是否为活跃版本，必须是非活跃版本的才能被读到，若当前记录为活跃状态，则根据记录的 回滚指针 从 undo log 中找到这条记录的上一个版本在进行判断，直到找到对当前查询可见的版本返回

总结

一条数据在修改时，会根据列中存在的隐式字段与 undo 日志生成一条记录的版本线性表（版本链），在查询时会生成 Read View，根据 Read View 中的内容，依次从版本链中找到对于当前查询可见的记录。而在一个事务中 Read View 生成的时机决定了 读已提交和可重复读 的差异。