MySQL高级【MVCC原理分析】

逃离我推掉我的手 2023-10-03 23:39 55阅读 0赞

## 1：MVCC ##

### 1.1：基本概念 ###

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

![b9e368a6c1434e1abd76f16e4b662a0b.png][]

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

![384e5af3c55f4573a599bed20bdc8710.png][]

2). 快照读 简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据， 不加锁，是非阻塞读。 • Read Committed：每次select，都生成一个快照读。 • Repeatable Read：开启事务后第一个select语句才是快照读的地方。 • Serializable：快照读会退化为当前读。 测试:

![74a40f0be0544b44b1b9b31d6ccb654a.png][]

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

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

接下来，我们再来介绍一下InnoDB引擎的表中涉及到的隐藏字段 、undolog 以及 readview，从 而来介绍一下MVCC的原理。

### 1.2：隐藏字段 ###

#### 1.2.1：介绍 ####

![2a933191a00246eea6c460e103632009.png][]

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

![71ec8071865b4082bd6e2351859cd735.png][]

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

#### 1.2.2：测试 ####

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

ibd2sdi stu.ibd

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

![db14ee04b87f4e238f5f169489f7bf35.png][]

![5b2ea98938434f899b1746df0b29f1b2.png][]

2). 查看没有主键的表 employee 建表语句：

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

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

ibd2sdi employee.ibd

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

![24a74019260442329e98dc0c9e3fe64d.png][]

![8958be7f4f2a459fbdfbc8463481f1e4.png][]

![8668e768da644b29976fd3476a6293e1.png][]

### 1.3：undo log ###

#### 1.3.1：介绍 ####

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

#### 1.3.2：版本链 ####

有一张表原始数据为：

![4b5e94a26c604d9f87a4964d347b85e7.png][]

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

然后，有四个并发事务同时在访问这张表。 A. 第一步

![bb86c12a7a3e45859091e1a74db27a1b.png][]

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

![41549a1b87dd4d52b37dc691c6b320ce.png][]

B.第二步

![ca5c715d692f4e4b9f1608adfe0e4437.png][]

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

![56bf4739ec2441e4af351e8bb1414950.png][]

C. 第三步

![efae8d2ef3824e068276ec706c9c6452.png][]

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

![45af7515cce14ca887079f0daa8b31dc.png][]

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

### 1.4：readview ###

ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务 （未提交的）id。 ReadView中包含了四个核心字段：

![9dc370e63de34d108e43bc51e4671524.png][]

而在readview中就规定了版本链数据的访问规则： trx\_id 代表当前undolog版本链对应事务ID。

![b4fe28f8b3c7437c8c5e7a7229507e24.png][]

不同的隔离级别，生成ReadView的时机不同： 1：READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。 2：REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

### 1.5：原理分析 ###

#### 1.5.1：RC隔离级别 ####

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

![1e18f111285541ee9b8e83072930f576.png][]

那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则， 到undolog版本链中匹配数据，最终决定此次快照读返回的数据。 A. 先来看第一次快照读具体的读取过程：

![7c60c20744c641caa781a5112d225690.png][]

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

*  先匹配

![3d6e5db9d41b40758c1a9d1edd39c442.png][]

这条记录，这条记录对应的 trx\_id为4，也就是将4带入右侧的匹配规则中。 ①不满足 ②不满足 ③不满足 ④也不满足 ， 都不满足，则继续匹配undo log版本链的下一条。

*  再匹配第二条

![d9f2eb5853064744b166a89cded8d80d.png][]

这条 记录对应的trx\_id为3，也就是将3带入右侧的匹配规则中。①不满足 ②不满足 ③不满足 ④也 不满足 ，都不满足，则继续匹配undo log版本链的下一条。

*  再匹配第三条

![2597f0a11ba74a59a22472d898bec2bf.png][]

录对应的trx\_id为2，也就是将2带入右侧的匹配规则中。①不满足 ②满足 终止匹配，此次快照 读，返回的数据就是版本链中记录的这条数据。

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

![ed2bd597086d4d5c99a288b13598ca52.png][]

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

![649e5af55460456391d9ba1887deba93.png][]

#### 1.5.2：RR隔离级别 ####

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可 重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。 那MySQL是如何做到可重复读的呢? 我们简单分析一下就知道了

![28b2cfe1f6944b459614eaf7fd7b41b3.png][]

我们看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该 ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返 回的结果也是一样的。

所以呢，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

![2b279a3219d743aa805577c900ea50d1.png][]

[b9e368a6c1434e1abd76f16e4b662a0b.png]: https://img-blog.csdnimg.cn/img_convert/b9e368a6c1434e1abd76f16e4b662a0b.png
[384e5af3c55f4573a599bed20bdc8710.png]: https://img-blog.csdnimg.cn/img_convert/384e5af3c55f4573a599bed20bdc8710.png
[74a40f0be0544b44b1b9b31d6ccb654a.png]: https://img-blog.csdnimg.cn/img_convert/74a40f0be0544b44b1b9b31d6ccb654a.png
[2a933191a00246eea6c460e103632009.png]: https://img-blog.csdnimg.cn/img_convert/2a933191a00246eea6c460e103632009.png
[71ec8071865b4082bd6e2351859cd735.png]: https://img-blog.csdnimg.cn/img_convert/71ec8071865b4082bd6e2351859cd735.png
[db14ee04b87f4e238f5f169489f7bf35.png]: https://img-blog.csdnimg.cn/img_convert/db14ee04b87f4e238f5f169489f7bf35.png
[5b2ea98938434f899b1746df0b29f1b2.png]: https://img-blog.csdnimg.cn/img_convert/5b2ea98938434f899b1746df0b29f1b2.png
[24a74019260442329e98dc0c9e3fe64d.png]: https://img-blog.csdnimg.cn/img_convert/24a74019260442329e98dc0c9e3fe64d.png
[8958be7f4f2a459fbdfbc8463481f1e4.png]: https://img-blog.csdnimg.cn/img_convert/8958be7f4f2a459fbdfbc8463481f1e4.png
[8668e768da644b29976fd3476a6293e1.png]: https://img-blog.csdnimg.cn/img_convert/8668e768da644b29976fd3476a6293e1.png
[4b5e94a26c604d9f87a4964d347b85e7.png]: https://img-blog.csdnimg.cn/img_convert/4b5e94a26c604d9f87a4964d347b85e7.png
[bb86c12a7a3e45859091e1a74db27a1b.png]: https://img-blog.csdnimg.cn/img_convert/bb86c12a7a3e45859091e1a74db27a1b.png
[41549a1b87dd4d52b37dc691c6b320ce.png]: https://img-blog.csdnimg.cn/img_convert/41549a1b87dd4d52b37dc691c6b320ce.png
[ca5c715d692f4e4b9f1608adfe0e4437.png]: https://img-blog.csdnimg.cn/img_convert/ca5c715d692f4e4b9f1608adfe0e4437.png
[56bf4739ec2441e4af351e8bb1414950.png]: https://img-blog.csdnimg.cn/img_convert/56bf4739ec2441e4af351e8bb1414950.png
[efae8d2ef3824e068276ec706c9c6452.png]: https://img-blog.csdnimg.cn/img_convert/efae8d2ef3824e068276ec706c9c6452.png
[45af7515cce14ca887079f0daa8b31dc.png]: https://img-blog.csdnimg.cn/img_convert/45af7515cce14ca887079f0daa8b31dc.png
[9dc370e63de34d108e43bc51e4671524.png]: https://img-blog.csdnimg.cn/img_convert/9dc370e63de34d108e43bc51e4671524.png
[b4fe28f8b3c7437c8c5e7a7229507e24.png]: https://img-blog.csdnimg.cn/img_convert/b4fe28f8b3c7437c8c5e7a7229507e24.png
[1e18f111285541ee9b8e83072930f576.png]: https://img-blog.csdnimg.cn/img_convert/1e18f111285541ee9b8e83072930f576.png
[7c60c20744c641caa781a5112d225690.png]: https://img-blog.csdnimg.cn/img_convert/7c60c20744c641caa781a5112d225690.png
[3d6e5db9d41b40758c1a9d1edd39c442.png]: https://img-blog.csdnimg.cn/img_convert/3d6e5db9d41b40758c1a9d1edd39c442.png
[d9f2eb5853064744b166a89cded8d80d.png]: https://img-blog.csdnimg.cn/img_convert/d9f2eb5853064744b166a89cded8d80d.png
[2597f0a11ba74a59a22472d898bec2bf.png]: https://img-blog.csdnimg.cn/img_convert/2597f0a11ba74a59a22472d898bec2bf.png
[ed2bd597086d4d5c99a288b13598ca52.png]: https://img-blog.csdnimg.cn/img_convert/ed2bd597086d4d5c99a288b13598ca52.png
[649e5af55460456391d9ba1887deba93.png]: https://img-blog.csdnimg.cn/img_convert/649e5af55460456391d9ba1887deba93.png
[28b2cfe1f6944b459614eaf7fd7b41b3.png]: https://img-blog.csdnimg.cn/img_convert/28b2cfe1f6944b459614eaf7fd7b41b3.png
[2b279a3219d743aa805577c900ea50d1.png]: https://img-blog.csdnimg.cn/img_convert/2b279a3219d743aa805577c900ea50d1.png