聊一聊MySQL的MVCC实现原理

约定不等于承诺〃 2023-10-04 12:34 15阅读 0赞

### 一、MVCC相关概念 ###

#### 1. MVCC概述 ####

MVCC（Multi-Version Concurrency Control | 多版本并发控制），利用记录的`版本链`和`ReadView`，来控制并发事务访问相同记录时的行为。

*  在每次更新该记录后，都会将旧值放到一条undo log中。随着更新次数的增多，所有的版本都会被roll\_pointer属性连接成一条链表，这个链表也就是`版本链`。

**作用：**

*  为了提高数据库并发性能，用更好的方式去处理读写冲突。
 *  做到即使有读写冲突，也可以不加锁，非阻塞并发读。

#### 2. MVCC解决的问题 ####

**数据库并发场景有三种**，分别是：

1.  **读读**：不存在任何问题，也不需要并发控制。
2.  **读写**：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读、幻读、不可重复读。
3.  **写写**：有线程安全问题，可能存在更新丢失问题。

MVCC是一种用来解决读写冲突的无锁并发控制，也就是为事务分配单项增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只是读该事务开始前的数据库快照，所以MVCC可以为数据库解决以下问题：

1.  在并发读写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能。
2.  解决脏读、幻读、不可重复度等事务隔离问题，但是不能解决更新丢失问题。

在聊MVCC的实现原理之前，我们先了解两个概念：当前读、快照读。

#### 3. 当前读 ####

像select … lock in share mode（共享锁）、select … for update；update、insert、delete(排他锁)这些操作都是一种当前读。

他们**读取的是记录的最新版本**，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

#### 4. 快照读 ####

**不加锁的select操作**是快照读，即不加锁的非阻塞读；其读取的是历史版本的数据。**串行化隔离级别下会退化成当前读**。  
快照读是基于提高并发性能的考量，快照读的实现是基于多版本并发控制MVCC。我们可以认为MVCC是行锁的一个变种。但它在很多情况下，其避免了加锁操作、降低了加锁解锁的开销。但既然是基于多版本，那么数据就有可能是**之前的版本**。

#### 5. 当前读、快照读、MVCC的关系 ####

MVCC多版本并发控制指的是维持一个数据的多个版本，使得读写操作没有冲突，快照读是MySQL实现MVCC的一个非阻塞读功能。

MVCC模块在MySQL中的具体实现是由三个隐式字段，undoLog、read view三个组件来实现的

### 二、MVCC实现原理 ###

MVCC的实现原理主要依赖于记录中的三个隐藏字段、undoLog、read view来实现的。  
每行记录除了我们自定义的字段外，还有数据隐式定的一些字段，分别为：

*  **DB\_TRX\_ID**
    
    6字节，最近**修改事务ID**，记录这条记录或者最后一次修改该记录的事务ID
 *  **DB\_ROLL\_PTR**
    
    7字节，**回滚指针**，指向**这条记录的上一个版本，用于配合undoLog**。
 *  **DB\_ROW\_ID**
    
    6字节，**隐藏的主键**。如果表没有主键，会自动生成一个6字节的row\_id

![在这里插入图片描述][20210508080602788.png]  
在上图中，DB\_ROW\_ID是数据库默认为该行记录生成的唯一隐式主键，DB\_TRX\_ID是当前操作该记录的事务ID，DB\_ROLL\_PTR是一个回滚指针，用于配合undo log，指向上一个旧版本,第一次对数据进行操作时，该字段是没有值的。

#### 1. undo log ####

undolog是一个链表结构，最新的历史数据放在链表头，即`版本链`。其被称之为回滚日志，表示在进行insert，delete，update操作的时候产生的方便回滚的日志。

当进行insert操作的时候，产生的undolog只在事务回滚的时候需要，并且在事务提交之后可以被立刻丢弃。

当进行update和delete操作的时候，产生的undolog不仅仅在事务回滚的时候需要，在快照读的时候也需要，所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除（当数据发生更新和删除操作的时候都只是设置一下老记录的deleted\_bit，并不是真正的将过时的记录删除，因为为了节省磁盘空间，innodb有专门的purge线程来清除deleted\_bit为true的记录，如果某个记录的deleted\_id为true，并且DB\_TRX\_ID相对于purge线程的read view 可见，那么这条记录一定时可以被清除的）。

**下面我们看一下undo log生成的记录链**

1）假设有一个事务编号为1的事务向表中插入一条记录，那么此时行数据的状态为：  
![在这里插入图片描述][20210508080553125.png]  
2）假设有第二个事务编号为2对该记录的那么做出修改，改为lisi。

*  在事务2修改该行记录数据时，数据库会对该行加排他锁；
 *  然后把该行数据拷贝到undolog中，作为旧记录，即在undolog中有当前行的拷贝副本；
 *  拷贝完毕后，修改该行name为lisi，并且修改隐藏字段的事务ID为当前事务2的id，回滚指针指向已经拷贝到undolog的副本记录中。
 *  事务提交，释放锁。

![\*\*图片二\*\*][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70]  
3）假设有第三个事务编号为3对该记录的age做了修改，改为32。

*  在事务2修改该行数据时，数据库会对该行加排他锁。
 *  然后把该行数据拷贝到undolog中，做为旧记录，发现该行记录已经有undolog了，那么最新的旧数据作为链表的表头，插在该行记录的undolog的最前面。
 *  修改该行age为32岁，并且修改隐藏字段的事务id为当前事务3的id，回滚指针指向刚刚拷贝的undolog的副本记录。
 *  事务提交，释放锁。

![\*\*图片三\*\*][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 1]  
从上述的一系列图中，我们可以发现，不同事务或者相同事务的对同一记录的修改，会导致该记录的undolog生成一条记录版本线性表，即链表，undolog的链首就是最新的旧记录，链尾就是最早的旧记录。

#### 2. Read view ####

Read view 是**事务进行快照读操作时生产的读视图**。在该事务执行快照读的那一刻，会生成一个数据系统当前的快照，记录并维护系统当前活跃事务的id，事务的id值是递增的。

其实**Read View的最大作用**是用来做可见性判断的，也就是说当某个事务在执行快照读的时候，对该记录创建一个Read View的视图，把它当作条件去判断当前事务能够看到哪个版本的数据，有可能读取到的是最新的数据，也有可能读取的是当前行记录的undolog中某个版本的数据

Read View遵循的可见性算法主要是将要被修改的数据的最新记录中的trx\_id（当前事务id）取出来，与系统当前其他活跃事务的id去对比。如果trx\_id跟Read View的属性做了比较，不符合可见性，那么就通过DB\_ROLL\_PTR回滚指针去取出undolog中的trx\_id做比较，即遍历链表中的trx\_id，直到找到满足条件的trx\_id,这个trx\_id所在的旧记录就是当前事务能看到的最新老版本数据。

##### 1）Read View包含的内容 #####

*  **m\_ids**：一个数值列表，在生成ReadView时，当前系统中`活跃的读写事务`的事务ID列表。（1,2,3）
 *  **min\_trx\_id**：在生成ReadView时，当前系统中活跃的读写事务中`最小的事务ID`，即trx\_list中的最小值。（1）
 *  **max\_trx\_id**：在生成ReadView时，系统应该分配给`下一个事务的事务ID`值。（4）
 *  **creator\_trx\_id**：`生成该ReadView`的事务的事务ID。

##### 2）如何通过ReadView判断记录的某个版本是否可见？ #####

trx\_id为undo log版本链中旧记录的trx\_id。

>  *  如果**trx\_id == creator\_trx\_id**，则表明当前事务在访问它修改过的记录，所以该版本可以被当前事务访问。
>  *  如果**trx\_id < min\_trx\_id**，则表明生成该版本的事务，在当前事务生成ReadView之前已经提交了，所以该版本可以被当前事务访问。**否者继续往下走**
>  *  如果**trx\_id >= max\_trx\_id**，这表明生成该版本的事务在当前事务生成ReadView之后才开启，所以该版本不可以被当前事务访问。**否者继续往下走**
>  *  判断trx\_id是否在m\_ids中：
>     
>      *  在，说明创建ReadView时，生成该版本旧记录的事务还是活跃的，事务没有commit，此版本的旧记录不对当前事务不可见。
>      *  不在，说明创建ReadView时，生成该版本的事务已经被提交commit，该版本可以被访问。

####  ####

#### 3. MVCC的整体处理流程 ####

假设有四个事务同时在执行，如下图所示：

<table> 
 <thead> 
  <tr> 
   <th align="center">事务1</th> 
   <th align="center">事务2</th> 
   <th align="center">事务3</th> 
   <th align="center">事务4</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">事务开始</td> 
   <td align="center">事务开始</td> 
   <td align="center">事务开始</td> 
   <td align="center">事务开始</td> 
  </tr> 
  <tr> 
   <td align="center">…</td> 
   <td align="center">…</td> 
   <td align="center">…</td> 
   <td align="center">修改且已提交</td> 
  </tr> 
  <tr> 
   <td align="center">进行中</td> 
   <td align="center">快照读</td> 
   <td align="center">进行中</td> 
   <td align="center"></td> 
  </tr> 
  <tr> 
   <td align="center">…</td> 
   <td align="center">…</td> 
   <td align="center">…</td> 
   <td align="center"></td> 
  </tr> 
 </tbody> 
</table>

从上述表格中，我们可以看到，当事务2对某行数据执行了快照读，数据库为该行数据生成一个Read View视图，可以看到事务1和事务3还在活跃状态，事务4在事务2快照读的前一刻提交了更新，所以，在Read View中记录了系统当前活跃事务1,3，维护在一个列表中。同时可以看到up\_limit\_id的值为1，而low\_limit\_id为5，如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 2]  
在上述的例子中，只有事务4修改过该行记录，并在事务2进行快照读前，提交了事务；所以该行当前数据的undolog如下所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 3]  
当事务2在快照读该行记录时，会拿着该行记录的DB\_TRX\_ID去跟up\_limit\_id,lower\_limit\_id和活跃事务列表进行比较，判读事务2能看到该行记录的版本是哪个？（此时暂不考虑事务隔离级别）

**具体流程如下：**

1.  先拿该行记录的事务ID（4）去跟Read View中的up\_limit\_id（1）相比较，判断是否小于。发现1 !< 4，继续往下走。
2.  继续判断事务ID（4）是否大于等于low\_limit\_id（5），发现4 !> 5，继续往下走。
3.  最后判断事务ID（4）是否在获取列表trx\_list（1,3）中，发现不在。所以事务4修改后的最新数据对事务2的快照是可见的。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 4]  
    最后我们再看看不同隔离级别下的快照读的不同。

#### 4. RC、RR级别下的Innodb快照读有什么不同？ ####

Read View生成的时机不同，从而造成RC、RR级别下快照读的结果的不同。

1、在RR级别下的某个事务的对某条记录的第一次快照读会创建一个快照即Read View,将当前系统活跃的其他事务记录起来，此后在调用快照读的时候，还是使用的是同一个Read View,所以只要当前事务在其他事务提交更新之前使用过快照读，那么之后的快照读使用的都是同一个Read View,所以对之后的修改不可见。

2、在RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动和事务的快照，这些事务的修改对于当前事务都是不可见的，而早于Read View创建的事务所做的修改均是可见

3、在RC级别下，事务中，每次快照读都会新生成一个快照和Read View,这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因。

**总结：**

1.  Read Committed -----在一个事务中，`每次读取数据`前都生成一个Read View。
2.  Repeatable Read -----在一个事务中，只在`第一次读取数据`时生成一个Read View。

也就是在**RC**隔离级别下，每个快照读都会生成并获取最新的Read View；而**RR**隔离级别下，只是同一个事务中的第一个快照读才会创建Read View，之后的快照读获取的都是同一个Read View。

[20210508080602788.png]: https://img-blog.csdnimg.cn/20210508080602788.png
[20210508080553125.png]: https://img-blog.csdnimg.cn/20210508080553125.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210508080656509.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210508080730585.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210508073745131.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210508073900844.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/2021050807475651.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1NhaW50bW0=,size_16,color_FFFFFF,t_70