【Mysql高级篇】MVCC的原理

冷不防 2024-04-01 12:41 59阅读 0赞

#### MVCC的原理 ####

*  MVCC原理
 *   *  前言
     *  版本链
     *  ReadView
     *   *  READ COMMITTED —— 每次读取数据前都生成一个ReadView
         *  REPEATABLE READ —— 在第一次读取数据时生成一个ReadView
     *  可重复读是如何工作的?
     *  读提交是如何工作的？
     *  总结
     *  思维导图

## MVCC原理 ##

### 前言 ###

本文摘自：

Mysql是怎样运行的：从根上理解Mysql

xiaolincoding.com

### 版本链 ###

我们前边说过，对于使用 InnoDB 存储引擎的表来说，**它的聚簇索引记录中都包含两个必要的隐藏列**（ row\_id 并 不是必要的，我们创建的表中有主键或者非NULL的UNIQUE键时都不会包含 row\_id 列）：

*  **trx\_id ：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的 事务id 赋值给 trx\_id 隐藏列。**
 *  **roll\_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志 中，然后这个隐藏 列就相当于一个指针，可以通过它来找到该记录修改前的信息。**

比方说我们的表 hero 现在只包含一条记录：

mysql> SELECT * FROM hero;
    +--------+--------+---------+
    | number | name | country |
    +--------+--------+---------+
    | 1 | 刘备 | 蜀 |
    +--------+--------+---------+
    1 row in set (0.07 sec)

假设插入该记录的 事务id 为 80 ，那么此刻该条记录的示意图如下所示：![image-20221026093301002][]

假设之后两个 事务id 分别为 100 、 200 的事务对这条记录进行 UPDATE 操作，操作流程如下：

![image-20221026093323415][]

每次对记录进行改动，都会记录一条 undo日志 ，每条 undo日志 也都有一个 roll\_pointer 属性（ INSERT 操作 对应的 undo日志 没有该属性，因为该记录并没有更早的版本），可以将这些 undo日志 都连起来，串成一个链表，所以现在的情况就像下图一样：

![image-20221026093342990][]

对该记录每次更新后，都会将旧值放到一条 undo日志 中，就算是该记录的一个旧版本，随着更新次数的增多， 所有的版本都会被 roll\_pointer 属性连接成一个链表，我们把这个链表称之为 `版本链` ，**版本链的头节点就是当 前记录最新的值**。另外，每个版本中还包含生成该版本时对应的 事务id ，这个信息很重要，我们稍后就会用到。

### ReadView ###

对于使用 `READ UNCOMMITTED`隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录 的最新版本就好了；对于使用`SERIALIZABLE`隔离级别的事务来说，设计 InnoDB 的大叔规定使用加锁的方式来访 问记录;对于使用 `READ COMMITTED` 和`REPEATABLE READ` 隔离级别的事务来 说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交， 是不能直接读取最新版本的记录的，核心问题就是：\*\*需要判断一下版本链中的哪个版本是当前事务可见的。\*\*为 此，设计 InnoDB 的大叔提出了一个 `ReadView`的概念，这个 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 。

> 小贴士： 我们前边说过，**只有在对表中的记录做改动时（执行INSERT、DELETE、UPDATE这些语句时）才会 为事务分配事务id，否则在一个只读事务中的事务id值都默认为0。**

有了这个 ReadView ，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：

*  如果被访问版本的 trx\_id 属性值与 ReadView 中的 creator\_trx\_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
 *  如果被访问版本的 trx\_id 属性值小于 ReadView 中的 min\_trx\_id 值，表明生成该版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
 *  如果被访问版本的 trx\_id 属性值大于 ReadView 中的 max\_trx\_id 值，表明生成该版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
 *  如果被访问版本的 trx\_id 属性值在 ReadView 的 min\_trx\_id 和 max\_trx\_id 之间，那就需要判断一下trx\_id 属性值是不是在 m\_ids 列表中，如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问。

如果某个版本的数据对当前事务不可见的话，那就顺着版本链找到下一个版本的数据，继续按照上边的步骤判断 可见性，依此类推，直到版本链中的最后一个版本。如果最后一个版本也不可见的话，那么就意味着该条记录对 该事务完全不可见，查询结果就不包含该记录。

在 MySQL 中， READ COMMITTED 和 REPEATABLE READ 隔离级别的的一个非常大的区别就是它们生成ReadView的 时机不同。我们还是以表 hero 为例来，假设现在表 hero 中只有一条由 事务id 为 80 的事务插入的一条记录：

接下来看一下 READ COMMITTED 和 REPEATABLE READ 所谓的生成ReadView的时机不同到底不同在哪里.

#### READ COMMITTED —— 每次读取数据前都生成一个ReadView ####

比方说现在系统里有两个 事务id 分别为 100 、 200 的事务在执行：

# Transaction 100
    BEGIN;
    UPDATE hero SET name = '关羽' WHERE number = 1;
    UPDATE hero SET name = '张飞' WHERE number = 1;
    # Transaction 200
    BEGIN;
    # 更新了一些别的表的记录
    ...

> 小贴士： 再次强调一遍，事务执行过程中，只有在第一次真正修改记录时（比如使用INSERT、DELETE、UPDATE语 句），才会被分配一个单独的事务id，这个事务id是递增的。所以我们才在Transaction 200中更新一 些别的表的记录，目的是让它分配事务id。

此刻，表 hero 中 number 为 1 的记录得到的版本链表如下所示：

![image-20221030185902795][]

假设现在有一个使用 READ COMMITTED 隔离级别的事务开始执行：

# 使用READ COMMITTED隔离级别的事务
    BEGIN;
    # SELECT1：Transaction 100、200未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'

这个 SELECT1 的执行过程如下：

*  在执行 SELECT 语句时会先生成一个 ReadView ， ReadView 的 m\_ids 列表的内容就是 \[100, 200\] ，min\_trx\_id 为 100 ， max\_trx\_id 为 201 ， creator\_trx\_id 为 0 。
 *  然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列 name 的内容是 ‘张飞’ ，该版本的trx\_id 值为 100 ，在 m\_ids 列表内，所以不符合可见性要求，根据 roll\_pointer 跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘关羽’ ，该版本的 trx\_id 值也为 100 ，也在 m\_ids 列表内，所以也不符合要求，继续跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘刘备’ ，该版本的 trx\_id 值为 80 ，小于 ReadView 中的 min\_trx\_id 值100 ，所以这个版本是符合要求的，最后返回给用户的版本就是这条列 name 为 ‘刘备’ 的记录。

之后，我们把 事务id 为 100 的事务提交一下，就像这样：

# Transaction 100
    BEGIN;
    UPDATE hero SET name = '关羽' WHERE number = 1;
    UPDATE hero SET name = '张飞' WHERE number = 1;
    COMMIT;

然后再到 事务id 为 200 的事务中更新一下表 hero 中 number 为 1 的记录：

# Transaction 200
    BEGIN;
    # 更新了一些别的表的记录
    ...
    UPDATE hero SET name = '赵云' WHERE number = 1;
    UPDATE hero SET name = '诸葛亮' WHERE number = 1;

此刻，表 hero 中 number 为 1 的记录的版本链就长这样：

![image-20221030203335069][]

然后再到刚才使用 READ COMMITTED 隔离级别的事务中继续查找这个 number 为 1 的记录，如下：

# 使用READ COMMITTED隔离级别的事务
    BEGIN;
    # SELECT1：Transaction 100、200均未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'
    # SELECT2：Transaction 100提交，Transaction 200未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'张飞'

*  在执行 SELECT 语句时会又会单独生成一个 ReadView ，该 ReadView 的 m\_ids 列表的内容就是 \[200\] （ 事务id 为 100 的那个事务已经提交了，所以再次生成快照时就没有它了）， min\_trx\_id 为 200 ，max\_trx\_id 为 201 ， creator\_trx\_id 为 0 。
 *  然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列 name 的内容是 ‘诸葛亮’ ，该版本的trx\_id 值为 200 ，在 m\_ids 列表内，所以不符合可见性要求，根据 roll\_pointer 跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘赵云’ ，该版本的 trx\_id 值为 200 ，也在 m\_ids 列表内，所以也不符合要求，继续跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘张飞’ ，该版本的 trx\_id 值为 100 ，小于 ReadView 中的 min\_trx\_id 值200 ，所以这个版本是符合要求的，最后返回给用户的版本就是这条列 name 为 ‘张飞’ 的记录。

以此类推，如果之后 事务id 为 200 的记录也提交了，再此在使用 READ COMMITTED 隔离级别的事务中查询表 hero 中 number 值为 1 的记录时，得到的结果就是 ‘诸葛亮’ 了，具体流程我们就不分析了。总结一下就是：**使 用READ COMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。**

#### REPEATABLE READ —— 在第一次读取数据时生成一个ReadView ####

对于使用 REPEATABLE READ 隔离级别的事务来说，只会在第一次执行查询语句时生成一个 ReadView ，之后的查 询就不会重复生成了。我们还是用例子看一下是什么效果。

比方说现在系统里有两个 事务id 分别为 100 、 200 的事务在执行

此刻，表 hero 中 number 为 1 的记录得到的版本链表如下所示：

![image-20221030205921663][]

假设现在有一个使用 REPEATABLE READ 隔离级别的事务开始执行：

# 使用REPEATABLE READ隔离级别的事务
    BEGIN;
    # SELECT1：Transaction 100、200未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'

这个 SELECT1 的执行过程如下：

之后，我们把 事务id 为 100 的事务提交一下，就像这样：

# Transaction 100
    BEGIN;
    UPDATE hero SET name = '关羽' WHERE number = 1;
    UPDATE hero SET name = '张飞' WHERE number = 1;
    COMMIT;

然后再到 事务id 为 200 的事务中更新一下表 hero 中 number 为 1 的记录：

# Transaction 200
    BEGIN;
    # 更新了一些别的表的记录
    ...
    UPDATE hero SET name = '赵云' WHERE number = 1;
    UPDATE hero SET name = '诸葛亮' WHERE number = 1;

此刻，表 hero 中 number 为 1 的记录的版本链就长这样：

![image-20221030210144487][]

然后再到刚才使用 REPEATABLE READ 隔离级别的事务中继续查找这个 number 为 1 的记录，如下：

# 使用REPEATABLE READ隔离级别的事务
    BEGIN;
    # SELECT1：Transaction 100、200均未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值为'刘备'
    # SELECT2：Transaction 100提交，Transaction 200未提交
    SELECT * FROM hero WHERE number = 1; # 得到的列name的值仍为'刘备'

这个 SELECT2 的执行过程如下：

*  因为当前事务的隔离级别为 REPEATABLE READ ，而之前在执行 SELECT1 时已经生成过 ReadView 了，所以此 时直接复用之前的 ReadView ，之前的 ReadView 的 m\_ids 列表的内容就是 \[100, 200\] ， min\_trx\_id 为 100 ， max\_trx\_id 为 201 ， creator\_trx\_id 为 0 。
 *  然后从版本链中挑选可见的记录，从图中可以看出，最新版本的列 name 的内容是 ‘诸葛亮’ ，该版本的 trx\_id 值为 200 ，在 m\_ids 列表内，所以不符合可见性要求，根据 roll\_pointer 跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘赵云’ ，该版本的 trx\_id 值为 200 ，也在 m\_ids 列表内，所以也不符合 要求，继续跳到下一个版本。
 *  下一个版本的列 name 的内容是 ‘张飞’ ，该版本的 trx\_id 值为 100 ，而 m\_ids 列表中是包含值为 100 的 事务id 的，所以该版本也不符合要求，同理下一个列 name 的内容是 ‘关羽’ 的版本也不符合要求。继续跳 到下一个版本。
 *  下一个版本的列 name 的内容是 ‘刘备’ ，该版本的 trx\_id 值为 80 ，小于 ReadView 中的 min\_trx\_id 值 100 ，所以这个版本是符合要求的，最后返回给用户的版本就是这条列 c 为 ‘刘备’ 的记录。

也就是说两次 SELECT 查询得到的结果是重复的，记录的列 c 值都是 ‘刘备’ ，这就是 可重复读 的含义。如果我 们之后再把 事务id 为 200 的记录提交了，然后再到刚才使用 REPEATABLE READ 隔离级别的事务中继续查找这 个 number 为 1 的记录，得到的结果还是 ‘刘备’

![image-20221027093520558][]

### 可重复读是如何工作的? ###

为了更好的理解MVCC,我们通过图解来加深印象

**可重复读隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View**。

假设事务 A （事务 id 为51）启动后，紧接着事务 B （事务 id 为52）也启动了，那这两个事务创建的 Read View 如下：

![image-20221030231407865][]

![image-20221030231509320][]

事务 A 和 事务 B 的 Read View 具体内容如下：

*  在事务 A 的 Read View 中，它的事务 id 是 51，由于它是第一个启动的事务，所以此时活跃事务的事务 id 列表就只有 51，活跃事务的事务 id 列表中最小的事务 id 是事务 A 本身，下一个事务 id 则是 52。
 *  在事务 B 的 Read View 中，它的事务 id 是 52，由于事务 A 是活跃的，所以此时活跃事务的事务 id 列表是 51 和 52，**活跃的事务 id 中最小的事务 id 是事务 A**，下一个事务 id 应该是 53。

接着，在可重复读隔离级别下，事务 A 和事务 B 按顺序执行了以下操作：

*  事务 B 读取小林的账户余额记录，读到余额是 100 万；
 *  事务 A 将小林的账户余额记录修改成 200 万，并没有提交事务；
 *  事务 B 读取小林的账户余额记录，读到余额还是 100 万；
 *  事务 A 提交事务；
 *  事务 B 读取小林的账户余额记录，读到余额依然还是 100 万；

接下来，跟大家具体分析下。

事务 B 第一次读小林的账户余额记录，在找到记录后，它会先看这条记录的 trx\_id，此时**发现 trx\_id 为 50，比事务 B 的 Read View 中的 min\_trx\_id 值（51）还小，这意味着修改这条记录的事务早就在事务 B 启动前提交过了，所以该版本的记录对事务 B 可见的**，也就是事务 B 可以获取到这条记录。

接着，事务 A 通过 update 语句将这条记录修改了（还未提交事务），将小林的余额改成 200 万，这时 MySQL 会记录相应的 undo log，并以链表的方式串联起来，形成**版本链**，如下图：

![image-20221030232047906][]

![image-20221030232100507][]

然后事务 B 第二次去读取该记录，**发现这条记录的 trx\_id 值为 51，在事务 B 的 Read View 的 min\_trx\_id 和 max\_trx\_id 之间，则需要判断 trx\_id 值是否在 m\_ids 范围内，判断的结果是在的，那么说明这条记录是被还未提交的事务修改的，这时事务 B 并不会读取这个版本的记录。而是沿着 undo log 链条往下找旧版本的记录，直到找到 trx\_id 「小于」事务 B 的 Read View 中的 min\_trx\_id 值的第一条记录**，所以事务 B 能读取到的是 trx\_id 为 50 的记录，也就是小林余额是 100 万的这条记录。

最后，当事物 A 提交事务后，**由于隔离级别时「可重复读」，所以事务 B 再次读取记录时，还是基于启动事务时创建的 Read View 来判断当前版本的记录是否可见。所以，即使事物 A 将小林余额修改为 200 万并提交了事务， 事务 B 第三次读取记录时，读到的记录都是小林余额是 100 万的这条记录**。

就是通过这样的方式实现了，「可重复读」隔离级别下在事务期间读到的记录都是事务启动前的记录。

### 读提交是如何工作的？ ###

**读提交隔离级别是在每次读取数据时，都会生成一个新的 Read View**。

也意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。

那读提交隔离级别是怎么工作呢？我们还是以前面的例子来聊聊。

假设事务 A （事务 id 为51）启动后，紧接着事务 B （事务 id 为52）也启动了，接着按顺序执行了以下操作：

*  事务 B 读取数据（创建 Read View），小林的账户余额为 100 万；
 *  事务 A 修改数据（还没提交事务），将小林的账户余额从 100 万修改成了 200 万；
 *  事务 B 读取数据（创建 Read View），小林的账户余额为 100 万；
 *  事务 A 提交事务；
 *  事务 B 读取数据（创建 Read View），小林的账户余额为 200 万；

那具体怎么做到的呢？我们重点看事务 B 每次读取数据时创建的 Read View。前两次 事务 B 读取数据时创建的 Read View 如下图：

![image-20221030232442699][]

![image-20221030232502245][]

![image-20221030232527163][]

我们来分析下为什么事务 B 第二次读数据时，读不到事务 A （还未提交事务）修改的数据？

事务 B 在找到小林这条记录时，会看这条记录的 trx\_id 是 51，在事务 B 的 Read View 的 min\_trx\_id 和 max\_trx\_id 之间，接下来需要判断 trx\_id 值是否在 m\_ids 范围内，判断的结果是在的，那么说明**这条记录是被还未提交的事务修改的，这时事务 B 并不会读取这个版本的记录**。而是，沿着 undo log 链条往下找旧版本的记录，直到找到 trx\_id 「小于」事务 B 的 Read View 中的 min\_trx\_id 值的第一条记录，所以事务 B 能读取到的是 trx\_id 为 50 的记录，也就是小林余额是 100 万的这条记录。

我们来分析下为什么事务 A 提交后，事务 B 就可以读到事务 A 修改的数据？

在事务 A 提交后，**由于隔离级别是「读提交」，所以事务 B 在每次读数据的时候，会重新创建 Read View**，此时事务 B 第三次读取数据时创建的 Read View 如下：

事务 B 在找到小林这条记录时，**会发现这条记录的 trx\_id 是 51，比事务 B 的 Read View 中的 min\_trx\_id 值（52）还小，这意味着修改这条记录的事务早就在创建 Read View 前提交过了，所以该版本的记录对事务 B 是可见的**。

正是因为在读提交隔离级别下，事务每次读数据时都重新创建 Read View，那么在事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。

### 总结 ###

事务是在 MySQL 引擎层实现的，我们常见的 InnoDB 引擎是支持事务的，事务的四大特性是原子性、一致性、隔离性、持久性，我们这次主要讲的是隔离性。

当多个事务并发执行的时候，会引发脏读、不可重复读、幻读这些问题，那为了避免这些问题，SQL 提出了四种隔离级别，分别是读未提交、读已提交、可重复读、串行化，从左往右隔离级别顺序递增，隔离级别越高，意味着性能越差，InnoDB 引擎的默认隔离级别是可重复读。

要解决脏读现象，就要将隔离级别升级到读已提交以上的隔离级别，要解决不可重复读现象，就要将隔离级别升级到可重复读以上的隔离级别。

而对于幻读现象，不建议将隔离级别升级为串行化，因为这会导致数据库并发时性能很差。MySQL InnoDB 引擎的默认隔离级别虽然是「可重复读」，但是它很大程度上避免幻读现象（并不是完全解决了，详见这篇[文章 (opens new window)][_opens new window]），解决的方案有两种：

*  针对**快照读**（普通 select 语句），是**通过 MVCC 方式解决了幻读**，因为可重复读隔离级别下，事务执行过程中看到的数据，一直跟这个事务启动时看到的数据是一致的，即使中途有其他事务插入了一条数据，是查询不出来这条数据的，所以就很好了避免幻读问题。
 *  针对**当前读**（select … for update 等语句），是**通过 next-key lock（记录锁+间隙锁）方式解决了幻读**，因为当执行 select … for update 语句的时候，会加上 next-key lock，如果有其他事务在 next-key lock 锁范围内插入了一条记录，那么这个插入语句就会被阻塞，无法成功插入，所以就很好了避免幻读问题。

对于「读提交」和「可重复读」隔离级别的事务来说，它们是通过 Read View 来实现的，它们的区别在于创建 Read View 的时机不同：

*  「读提交」隔离级别是在每个 select 都会生成一个新的 Read View，也意味着，事务期间的多次读取同一条数据，前后两次读的数据可能会出现不一致，因为可能这期间另外一个事务修改了该记录，并提交了事务。
 *  「可重复读」隔离级别是启动事务时生成一个 Read View，然后整个事务期间都在用这个 Read View，这样就保证了在事务期间读到的数据都是事务启动前的记录。

这两个隔离级别实现是通过「事务的 Read View 里的字段」和「记录中的两个隐藏列」的比对，来控制并发事务访问同一个记录时的行为，这就叫 MVCC（多版本并发控制）。

在可重复读隔离级别中，普通的 select 语句就是基于 MVCC 实现的快照读，也就是不会加锁的。而 select … for update 语句就不是快照读了，而是当前读了，也就是每次读都是拿到最新版本的数据，但是它会对读到的记录加上 next-key lock 锁。

### 思维导图 ###

![在这里插入图片描述][4ce420066b584acd9b30a64d7aaf0a8c.png]

[image-20221026093301002]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b0ffd73b290e460e8011342fa78fe529.png
[image-20221026093323415]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/fb3a5e692f394057b00d11330a014f92.png
[image-20221026093342990]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/e128b4f76a284438a8d0ff8c2922cc31.png
[image-20221030185902795]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/bcd2306b14f24404ad30603caa433e93.png
[image-20221030203335069]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/643e591758b44ac3955f421c90321def.png
[image-20221030205921663]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/70c86339318c4704a5c16429ce143420.png
[image-20221030210144487]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/93f1701cb30b49b286ba7e04f9bb0c96.png
[image-20221027093520558]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b9d079642a734f7ca7a29abacd217c9d.png
[image-20221030231407865]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f983a041df854a028fb8aecb97ddec60.png
[image-20221030231509320]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6a23c386b68d404ba91dca931b241c3a.png
[image-20221030232047906]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/1fd5483d4fd44ce2a077cdbd49b616d0.png
[image-20221030232100507]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/df49e6800c5b496d8ef0814fdd8d778e.png
[image-20221030232442699]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/f3aea1edae08450fab1724528eaac62d.png
[image-20221030232502245]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/bc80d4d179e14a8d97d2be75dc685f61.png
[image-20221030232527163]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2d1ba128147f4173ab386c1ee9655ef1.png
[_opens new window]: https://xiaolincoding.com/mysql/transaction/phantom.html
[4ce420066b584acd9b30a64d7aaf0a8c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/83d93c1527814ea2a52e4db6895f1d30.png