MySQL-MVCC（多版本并发控制）

柔情只为你懂 2023-10-08 17:03 59阅读 0赞

#### 文章目录 ####

*  一、基本概念
 *   *  1、当前读
     *  2、快照读
     *  3、MVCC
 *  二、隐藏字段
 *   *  1、介绍
     *  2、测试
 *  三、undolog
 *   *  1、介绍
     *  2、版本链
 *  四、readview
 *  五、原理分析
 *   *  1、RC隔离级别
     *  2、RR隔离级别

## 一、基本概念 ##

### 1、当前读 ###

**读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁**。对于日常的操作，如：select … lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读。

测试：

![在这里插入图片描述][cf40d0c0259d4c8fa0207fc0ef5161e9.png_pic_center]

在测试中可以看到，即使是在默认的RR隔离级别下，事务A中依然可以读取到事务B最新提交的内容，因为在查询语句后面加上了 lock in share mode 共享锁，此时是当前读操作。当然，当加排他锁的时候，也是当前读操作。

### 2、快照读 ###

**简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据， 不加锁，是非阻塞读**。

Read Committed：每次select，都生成一个快照读。

Repeatable Read：开启事务后第一个select语句才是快照读的地方。

Serializable：快照读会退化为当前读。

测试：

![在这里插入图片描述][95afa008161f4c98a7d8f4001ed59089.png_pic_center]

在测试中,我们看到即使事务B提交了数据,事务A中也查询不到。 原因就是因为普通的select是快照读，而在当前默认的RR隔离级别下，开启事务后第一个select语句才是快照读的地方，后面执行相同的select语句都是从快照中获取数据，可能不是当前的最新数据，这样也就保证了可重复读。

### 3、MVCC ###

** 全称Multi-Version Concurrency Control**，多版本并发控制。指维护一个数据的多个版本， 使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。**MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView**。

InnoDB引擎的表中涉及到的隐藏字段 、undolog 以及 readview，以下是MVCC的原理。

## 二、隐藏字段 ##

### 1、介绍 ###

![在这里插入图片描述][3674648b178341198a6d2d9b55fb62ad.png_pic_center]

当创建了上面的这张表，我们在查看表结构的时候，就可以显式的看到这三个字段。 实际上除了这三个字段以外，InnoDB还会自动的给我们添加三个隐藏字段及其含义分别是：

<table> 
 <thead> 
  <tr> 
   <th>隐藏字段</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><font><strong>DB_TRX_ID</strong></font></td> 
   <td><font><strong>最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID</strong>。</font></td> 
  </tr> 
  <tr> 
   <td><font><strong>DB_ROLL_PTR</strong></font></td> 
   <td><font><strong>回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个版本</strong>。</font></td> 
  </tr> 
  <tr> 
   <td><font><strong>DB_ROW_ID</strong></font></td> 
   <td><font><strong>隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段</strong>。</font></td> 
  </tr> 
 </tbody> 
</table>

而上述的前两个字段是肯定会添加的， 是否添加最后一个字段DB\_ROW\_ID，得看当前表有没有主键， 如果有主键，则不会添加该隐藏字段。

### 2、测试 ###

（1）查看有主键的表 stu

进入服务器中的 /var/lib/mysql/itcast/ , 查看stu的表结构信息, 通过如下指令:

ibd2sdi stu.ibd

查看到的表结构信息中，有一栏 columns，在其中我们会看到处理我们建表时指定的字段以外，还有额外的两个字段 分别是：DB\_TRX\_ID 、 DB\_ROLL\_PTR ，因为该表有主键，所以没有DB\_ROW\_ID 隐藏字段。

（2）查看没有主键的表 employee

建表语句：

create table employee (id int , name varchar(10));

再通过以下指令来查看表结构及其其中的字段信息：

ibd2sdi employee.ibd

查看到的表结构信息中，有一栏 columns，在其中我们会看到处理我们建表时指定的字段以外，还有额外的三个字段分别是：DB\_TRX\_ID 、 DB\_ROLL\_PTR 、DB\_ROW\_ID，因为employee表是没有指定主键的。

## 三、undolog ##

### 1、介绍 ###

**回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志**。 当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。

### 2、版本链 ###

有一张表原始数据为：

![在这里插入图片描述][4ea0f1b68ccb4f2d90bf375e087562e0.png_pic_center]

**DB\_TRX\_ID : 代表最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID，是自增的。 DB\_ROLL\_PTR ： 由于这条数据是才插入的，没有被更新过，所以该字段值为null**

然后，有四个并发事务同时在访问这张表。

A. 第一步

![在这里插入图片描述][aeaa2c6d291e49de95ad5f53e1cabcdc.png_pic_center]

当事务2执行第一条修改语句时，会记录undo log日志，记录数据变更之前的样子; 然后更新记录， 并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

![在这里插入图片描述][7c4eed6dc6a849c4bd3284344aaeb1d1.png_pic_center]

B.第二步

![在这里插入图片描述][920aa5059c3b4913a954344192b81f78.png_pic_center]

当事务3执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记 录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

![在这里插入图片描述][34c260db652a4054b5413cbdab24f35d.png_pic_center]

C. 第三步

![在这里插入图片描述][00dc49eace514ad4a68446450dc36f54.png_pic_center]

当事务4执行第一条修改语句时，也会记录undo log日志，记录数据变更之前的样子; 然后更新记 录，并且记录本次操作的事务ID，回滚指针，回滚指针用来指定如果发生回滚，回滚到哪一个版本。

![在这里插入图片描述][699ac4a97b3f4f719e9ec07ce300abc8.png_pic_center]

> 最终发现，不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条 记录版本链表，链表的头部是最新的旧记录，链表尾部是最早的旧记录。

## 四、readview ##

ReadView（读视图）是快照读 SQL执行时MVCC提取数据的依据，**记录并维护系统当前活跃的事务 （未提交的）id。**

ReadView中包含了四个核心字段：

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>m_ids</td> 
   <td>当前活跃的事务ID集合</td> 
  </tr> 
  <tr> 
   <td>min_trx_id</td> 
   <td>最小活跃事务ID</td> 
  </tr> 
  <tr> 
   <td>max_trx_id</td> 
   <td>预分配事务ID，当前最大事务ID+1（因为事务ID是自增的）</td> 
  </tr> 
  <tr> 
   <td>creator_trx_id</td> 
   <td>ReadView创建者的事务ID</td> 
  </tr> 
 </tbody> 
</table>

而在readview中就规定了版本链数据的访问规则：

trx\_id 代表当前undolog版本链对应事务ID。

<table> 
 <thead> 
  <tr> 
   <th>条件</th> 
   <th>是否可以访问</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>trx_id == creator_trx_id</td> 
   <td>可以访问该版本</td> 
   <td>成立，说明数据是当前这个事 务更改的。</td> 
  </tr> 
  <tr> 
   <td>trx_id &lt; min_trx_id</td> 
   <td>可以访问该版本</td> 
   <td>成立，说明数据已经提交了。</td> 
  </tr> 
  <tr> 
   <td>trx_id &gt; max_trx_id</td> 
   <td>不可以访问该版本</td> 
   <td>成立，说明该事务是在 ReadView生成后才开启。</td> 
  </tr> 
  <tr> 
   <td>min_trx_id &lt;= trx_id &lt;= max_trx_id</td> 
   <td>如果trx_id不在m_ids中， 是可以访问该版本的</td> 
   <td>成立，说明数据已经提交。</td> 
  </tr> 
 </tbody> 
</table>

不同的隔离级别，生成ReadView的时机不同：

READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。

REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

## 五、原理分析 ##

### 1、RC隔离级别 ###

RC隔离级别下，在事务中每一次执行快照读时生成ReadView。

分析事务5中，两次快照读读取数据，是如何获取数据的? **在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下**。

![在这里插入图片描述][8c699c0c452245dea98aa634a54b3b78.png_pic_center]

那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则，到undolog版本链中匹配数据，最终决定此次快照读返回的数据。

A. 先来看第一次快照读具体的读取过程：

![在这里插入图片描述][279676db08354de7a17c792b50a18be4.png_pic_center]

![在这里插入图片描述][4b028a0432034e359e0703835c966da1.png_pic_center]

在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

*  先匹配 ![在这里插入图片描述][244102b61a5b4cfe9e8ca77eee6cfe49.png]  
    这条记录，这条记录对应的 trx\_id为4，也就是将4带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也不满足 ， 都不满足，则继续匹配undo log版本链的下一条。
 *  再匹配第二条![在这里插入图片描述][be4139e3f1ce441a82ff88872239ca47.png]  
    ，这条 记录对应的trx\_id为3，也就是将3带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也不满足 ，都不满足，则继续匹配undo log版本链的下一条。
 *  再匹配第三条 ![在这里插入图片描述][dd4d79dc89e94cd38fac30267f234eaf.png]  
    ，这条记 录对应的trx\_id为2，也就是将2带入右侧的匹配规则中。①不满足 ②满足终止匹配，此次快照读，返回的数据就是版本链中记录的这条数据。

B. 再来看第二次快照读具体的读取过程:

![在这里插入图片描述][56f55dd6f4c2480586bab06a72ebc9e4.png_pic_center]  
![在这里插入图片描述][f1f67569eae74345ace8a63806cc1774.png_pic_center]

在进行匹配时，会从undo log的版本链，从上到下进行挨个匹配：

*  先匹配 ![在这里插入图片描述][4fe2ca4a77da4ae098805926fbe2b8bc.png_pic_center]  
    这条记录，这条记录对应的 trx\_id为4，也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ， 都不满足，则继续匹配undo log版本链的下一条。
 *  再匹配第二条 ![在这里插入图片描述][5650f3085a4f4826a95ea35a68f4a7fd.png_pic_center]  
    ，这条记录对应的trx\_id为3，也就是将3带入右侧的匹配规则中。①不满足 ②满足 。终止匹配，此次快照读，返回的数据就是版本链中记录的这条数据。

### 2、RR隔离级别 ###

**RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView**。**而RR 是可重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。**

**MySQL是如何做到可重复读**的呢?简单分析

![在这里插入图片描述][6ee53a3a11d44479b27f44d5c029cfc2.png]

看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该 ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返 回的结果也是一样的。所以呢，**MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的**。而**MVCC + 锁，则实现了事务的隔离性。** 而**一致性则是由redolog 与 undolog保证。**

![在这里插入图片描述][dd59e9ea4382484d843ee0f83a705d53.png_pic_center]

[cf40d0c0259d4c8fa0207fc0ef5161e9.png_pic_center]: https://img-blog.csdnimg.cn/cf40d0c0259d4c8fa0207fc0ef5161e9.png#pic_center
[95afa008161f4c98a7d8f4001ed59089.png_pic_center]: https://img-blog.csdnimg.cn/95afa008161f4c98a7d8f4001ed59089.png#pic_center
[3674648b178341198a6d2d9b55fb62ad.png_pic_center]: https://img-blog.csdnimg.cn/3674648b178341198a6d2d9b55fb62ad.png#pic_center
[4ea0f1b68ccb4f2d90bf375e087562e0.png_pic_center]: https://img-blog.csdnimg.cn/4ea0f1b68ccb4f2d90bf375e087562e0.png#pic_center
[aeaa2c6d291e49de95ad5f53e1cabcdc.png_pic_center]: https://img-blog.csdnimg.cn/aeaa2c6d291e49de95ad5f53e1cabcdc.png#pic_center
[7c4eed6dc6a849c4bd3284344aaeb1d1.png_pic_center]: https://img-blog.csdnimg.cn/7c4eed6dc6a849c4bd3284344aaeb1d1.png#pic_center
[920aa5059c3b4913a954344192b81f78.png_pic_center]: https://img-blog.csdnimg.cn/920aa5059c3b4913a954344192b81f78.png#pic_center
[34c260db652a4054b5413cbdab24f35d.png_pic_center]: https://img-blog.csdnimg.cn/34c260db652a4054b5413cbdab24f35d.png#pic_center
[00dc49eace514ad4a68446450dc36f54.png_pic_center]: https://img-blog.csdnimg.cn/00dc49eace514ad4a68446450dc36f54.png#pic_center
[699ac4a97b3f4f719e9ec07ce300abc8.png_pic_center]: https://img-blog.csdnimg.cn/699ac4a97b3f4f719e9ec07ce300abc8.png#pic_center
[8c699c0c452245dea98aa634a54b3b78.png_pic_center]: https://img-blog.csdnimg.cn/8c699c0c452245dea98aa634a54b3b78.png#pic_center
[279676db08354de7a17c792b50a18be4.png_pic_center]: https://img-blog.csdnimg.cn/279676db08354de7a17c792b50a18be4.png#pic_center
[4b028a0432034e359e0703835c966da1.png_pic_center]: https://img-blog.csdnimg.cn/4b028a0432034e359e0703835c966da1.png#pic_center
[244102b61a5b4cfe9e8ca77eee6cfe49.png]: https://img-blog.csdnimg.cn/244102b61a5b4cfe9e8ca77eee6cfe49.png
[be4139e3f1ce441a82ff88872239ca47.png]: https://img-blog.csdnimg.cn/be4139e3f1ce441a82ff88872239ca47.png
[dd4d79dc89e94cd38fac30267f234eaf.png]: https://img-blog.csdnimg.cn/dd4d79dc89e94cd38fac30267f234eaf.png
[56f55dd6f4c2480586bab06a72ebc9e4.png_pic_center]: https://img-blog.csdnimg.cn/56f55dd6f4c2480586bab06a72ebc9e4.png#pic_center
[f1f67569eae74345ace8a63806cc1774.png_pic_center]: https://img-blog.csdnimg.cn/f1f67569eae74345ace8a63806cc1774.png#pic_center
[4fe2ca4a77da4ae098805926fbe2b8bc.png_pic_center]: https://img-blog.csdnimg.cn/4fe2ca4a77da4ae098805926fbe2b8bc.png#pic_center
[5650f3085a4f4826a95ea35a68f4a7fd.png_pic_center]: https://img-blog.csdnimg.cn/5650f3085a4f4826a95ea35a68f4a7fd.png#pic_center
[6ee53a3a11d44479b27f44d5c029cfc2.png]: https://img-blog.csdnimg.cn/6ee53a3a11d44479b27f44d5c029cfc2.png
[dd59e9ea4382484d843ee0f83a705d53.png_pic_center]: https://img-blog.csdnimg.cn/dd59e9ea4382484d843ee0f83a705d53.png#pic_center