MySQL知识学习05（InnoDB存储引擎对MVCC的实现）

本是古典何须时尚 2024-03-22 12:03 4阅读 0赞

***1、一致性非锁定读和锁定读***

**一致性非锁定读**

对于 `一致性非锁定读（Consistent Nonlocking Reads）` ，通常做法是加一个版本号或者时间戳字段，在更新数据的同时版本号 + 1 或者更新时间戳。查询时，将当前可见的版本号与对应记录的版本号进行比对，如果记录的版本小于可见版本，则表示该记录可见

在 InnoDB 存储引擎中，`多版本控制 (multi versioning)` 就是对非锁定读的实现。如果读取的行正在执行 `DELETE` 或 `UPDATE` 操作，这时读取操作不会去等待行上锁的释放。相反地，`InnoDB` 存储引擎会去读取行的一个快照数据，对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)

`在 Repeatable Read 和 Read Committed 两个隔离级别下`，如果是执行普通的 select 语句（不包括 select … lock in share mode ,select … for update）则会使用 `一致性非锁定读（MVCC）`。并且在 `Repeatable Read` 下 `MVCC` 实现了**可重复读和防止部分幻读**

***2、锁定读***

如果执行的是下列语句，就是 `锁定读（Locking Reads`）

*  select … lock in share mode
 *  select … for update
 *  insert、update、delete 操作

在锁定读下，读取的是数据的最新版本，这种读也被称为 `当前读（current read）`。锁定读会对读取到的记录加锁：

*  select … lock in share mode：**对记录加 S 锁**，其它事务也可以加S锁，如果加 x 锁则会被阻塞
 *  select … for update、insert、update、delete：**对记录加 X 锁**，且其它事务不能加任何锁在一致性非锁定读下，即使读取的记录已被其它事务加上 X 锁，这时记录也是可以被读取的，即读取的快照数据。上面说了，在 Repeatable Read 下 MVCC 防止了部分幻读，这边的 “部分” 是指在 一致性非锁定读 情况下，只能读取到第一次查询之前所插入的数据（根据 Read View 判断数据可见性，Read View 在第一次查询时生成）。但是！如果是 当前读 ，每次读取的都是最新数据，这时如果两次查询中间有其它事务插入数据，就会产生幻读。所以， **InnoDB 在实现Repeatable Read 时，如果执行的是当前读，则会对读取的记录使用 Next-key Lock ，来防止其它事务在间隙间插入数据**

***3、InnoDB 对 MVCC 的实现***

**MVCC** 的实现依赖于：**隐藏字段、Read View、undo log**。在内部实现中，InnoDB 通过数据行的 **DB\_TRX\_ID** 和 **Read View** 来判断数据的可见性，如不可见，则通过数据行的 DB\_ROLL\_PTR 找到 **undo log** 中的历史版本。每个事务读到的数据版本可能是不一样的，**在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改**

**隐藏字段**

在内部，`InnoDB` 存储引擎为每行数据添加了三个 隐藏字段：

*  `DB_TRX_ID（6字节）`：表示最后一次插入或更新该行的事务 id。此外，delete 操作在内部被视为更新，只不过会在记录头 `Record header` 中的 `deleted_flag` 字段将其标记为已删除
 *  `DB_ROLL_PTR（7字节）` 回滚指针，指向该行的 `undo log` 。如果该行未被更新，则为空
 *  `DB_ROW_ID（6字节）`：如果没有设置主键且该表没有唯一非空索引时，InnoDB 会使用该 id 来生成聚簇索引

**ReadView**

class ReadView {
        
      /* ... */
    private:
      trx_id_t m_low_limit_id;      /* 大于等于这个 ID 的事务均不可见 */
    
      trx_id_t m_up_limit_id;       /* 小于这个 ID 的事务均可见 */
    
      trx_id_t m_creator_trx_id;    /* 创建该 Read View 的事务ID */
    
      trx_id_t m_low_limit_no;      /* 事务 Number, 小于该 Number 的 Undo Logs 均可以被 Purge */
    
      ids_t m_ids;                  /* 创建 Read View 时的活跃事务列表 */
    
      m_closed;                     /* 标记 Read View 是否 close */
    }

`Read View`主要是用来`做可见性判断`，**里面保存了 “当前对本事务不可见的其他活跃事务”**

主要有以下字段：

*  `m_low_limit_id`：目前出现过的最大的事务 ID+1，即下一个将被分配的事务 ID。大于等于这个 ID 的数据版本均不可见
 *  `m_up_limit_id`：活跃事务列表 m\_ids 中最小的事务 ID，如果 m\_ids 为空，则 m\_up\_limit\_id 为 m\_low\_limit\_id。小于这个 ID 的数据版本均可见
 *  `m_ids`：Read View 创建时其他未提交的活跃事务 ID 列表。创建 Read View时，将当前未提交事务 ID 记录下来，后续即使它们修改了记录行的值，对于当前事务也是不可见的。**m\_ids 不包括当前事务自己和已提交的事务**（正在内存中）
 *  `m_creator_trx_id`：创建该 Read View 的事务 ID

事务可见性示意图：

![在这里插入图片描述][9dbc6c90547a438b99735cb78a13fb13.png]

**undo-log**

undo log 主要有两个作用：

*  当事务回滚时用于将数据恢复到修改前的样子
 *  另一个作用是 `MVCC` ，当读取记录时，若该记录被其他事务占用或当前版本对该事务不可见，则可以通过 undo log 读取之前的版本数据，以此实现非锁定读

在 InnoDB 存储引擎中 undo log 分为两种： **insert undo log 和 update undo log**：

**1、insert undo log** ：指在 insert 操作中产生的 undo log。因为 insert 操作的记录只对事务本身可见，对其他事务不可见，故**该 undo log 可以在事务提交后直接删除。不需要进行 purge 操作**

`insert` 时的数据初始状态：

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

**2、update undo log** ：update 或 delete 操作中产生的 undo log。该 undo log可能需要提供 MVCC 机制，因此**不能在事务提交时就进行删除。提交时放入 undo log 链表，等待 purge线程 进行最后的删除**

数据第一次被修改时：

![在这里插入图片描述][109266dbd4c24e20bc32ce3b41be2ff4.png]

数据第二次被修改时：

![在这里插入图片描述][3b44867b13fb4926a545532b146d1ed9.png]

不同事务或者相同事务的对同一记录行的修改，会使该记录行的 undo log 成为一条链表，链首就是最新的记录，链尾就是最早的旧记录。

***4、数据可见性算法***

在 `InnoDB` 存储引擎中，创建一个新事务后，执行每个 `select` 语句前，都会创建一个**快照（Read View）**，**快照中保存了当前数据库系统中正处于活跃（没有 commit）的事务的 ID 号**。其实简单的说保存的是系统中当前不应该被本事务看到的其他事务 ID 列表（即 m\_ids）。当用户在这个事务中要读取某个记录行的时候，InnoDB 会将该记录行的 `DB_TRX_ID` 与 `Read View` 中的一些变量及当前事务 ID 进行比较，判断是否满足可见性条件

具体的比较算法如下：

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

1.  如果记录 DB\_TRX\_ID < m\_up\_limit\_id，那么表明最新修改该行的事务（DB\_TRX\_ID）在当前事务创建快照之前就提交了，所以该记录行的值对当前事务是可见的
2.  如果 DB\_TRX\_ID >= m\_low\_limit\_id，那么表明最新修改该行的事务（DB\_TRX\_ID）在当前事务创建快照之后才修改该行，所以该记录行的值对当前事务不可见。跳到步骤 5
3.  m\_ids 为空，则表明在当前事务创建快照之前，修改该行的事务就已经提交了，所以该记录行的值对当前事务是可见的
4.  如果 m\_up\_limit\_id <= DB\_TRX\_ID < m\_low\_limit\_id，表明最新修改该行的事务（DB\_TRX\_ID）在当前事务创建快照的时候可能处于“活动状态”或者“已提交状态”；**所以就要对活跃事务列表 m\_ids 进行查找（源码中是用的二分查找，因为是有序的）**  
    \--------如果在活跃事务列表 m\_ids 中能找到 DB\_TRX\_ID，表明：① 在当前事务创建快照前，该记录行的值被事务 ID 为 DB\_TRX\_ID 的事务修改了，但没有提交；或者 ② 在当前事务创建快照后，该记录行的值被事务 ID 为 DB\_TRX\_ID 的事务修改了。这些情况下，这个记录行的值对当前事务都是不可见的。跳到步骤 5  
    \--------在活跃事务列表中找不到，则表明“id 为 trx\_id 的事务”在修改“该记录行的值”后，在“当前事务”创建快照前就已经提交了，所以记录行对当前事务可见
5.  在该记录行的 DB\_ROLL\_PTR 指针所指向的 undo log 取出快照记录，用快照记录的 DB\_TRX\_ID 跳到步骤 1 重新开始判断，直到找到满足的快照版本或返回空

***5、RC 和 RR 隔离级别下 MVCC 的差异***

在事务隔离级别 RC 和 RR （InnoDB 存储引擎的默认事务隔离级别）下，InnoDB 存储引擎使用 MVCC（非锁定一致性读），但它们生成 Read View 的时机却不同

*  在 RC 隔离级别下的 每次select 查询前都生成一个Read View (m\_ids 列表)
 *  在 RR 隔离级别下只在事务开始后 第一次select 数据前生成一个Read View（m\_ids 列表）

***6、MVCC 解决不可重复读问题***

虽然 RC 和 RR 都通过 MVCC 来读取快照数据，但由于 **生成 Read View 时机不同**，从而在 RR 级别下实现可重复读

举个例子：

![在这里插入图片描述][92c68cf44c3f40189791f43fb90ac97d.png]

***7、在 RC 下 ReadView 生成情况***

1.  假设时间线来到 T4 ，那么此时数据行 id = 1 的版本链为：

![在这里插入图片描述][695017607eb6434b8944581a485e20e2.png]

由于 RC 级别下每次查询都会生成Read View ，并且事务 101、102 并未提交，此时 103 事务生成的 Read View 中活跃的事务 m\_ids 为：\[101,102\] ，m\_low\_limit\_id为：104，m\_up\_limit\_id为：101，m\_creator\_trx\_id 为：103

*  此时最新记录的 DB\_TRX\_ID 为 101，m\_up\_limit\_id <= 101 < m\_low\_limit\_id，所以要在 m\_ids 列表中查找，发现 DB\_TRX\_ID 存在列表中，那么这个记录不可见
 *  根据 DB\_ROLL\_PTR 找到 undo log 中的上一版本记录，上一条记录的 DB\_TRX\_ID 还是 101，不可见
 *  继续找上一条 DB\_TRX\_ID为 1，满足 1 < m\_up\_limit\_id，可见，所以事务 103 查询到数据为 name = 菜花

1.  时间线来到 T6 ，数据的版本链为：

![在这里插入图片描述][8679bb9bade94964bb66b179f4a6f5bb.png]

因为在 RC 级别下，重新生成 Read View，这时事务 101 已经提交，102 并未提交，所以此时 Read View 中活跃的事务 m\_ids：\[102\] ，m\_low\_limit\_id为：104，m\_up\_limit\_id为：102，m\_creator\_trx\_id为：103

*  此时最新记录的 DB\_TRX\_ID 为 102，m\_up\_limit\_id <= 102 < m\_low\_limit\_id，所以要在 m\_ids 列表中查找，发现 DB\_TRX\_ID 存在列表中，那么这个记录不可见
 *  根据 DB\_ROLL\_PTR 找到 undo log 中的上一版本记录，上一条记录的 DB\_TRX\_ID 为 101，满足 101 < m\_up\_limit\_id，记录可见，所以在 T6 时间点查询到数据为 name = 李四，与时间 T4 查询到的结果不一致，不可重复读！

1.  时间线来到 T9 ，数据的版本链为：

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

重新生成 Read View， 这时事务 101 和 102 都已经提交，所以 m\_ids 为空，则 m\_up\_limit\_id = m\_low\_limit\_id = 104，最新版本事务 ID 为 102，满足 102 < m\_low\_limit\_id，可见，查询结果为 name = 赵六

总结： **在 RC 隔离级别下，事务在每次查询开始时都会生成并设置新的 Read View，所以导致不可重复读**

***8、在 RR 下 ReadView 生成情况***

在可重复读级别下，**只会在事务开始后第一次读取数据时生成一个 Read View（m\_ids 列表）**

1.  在 T4 情况下的版本链为：

![在这里插入图片描述][503f9ccf4cab4c55a53dea8be3e4ca3a.png]

在当前执行 select 语句时生成一个 Read View，此时 m\_ids：\[101,102\] ，m\_low\_limit\_id为：104，m\_up\_limit\_id为：101，m\_creator\_trx\_id 为：103此时和 RC 级别下一样：

*  最新记录的 DB\_TRX\_ID 为 101，m\_up\_limit\_id <= 101 < m\_low\_limit\_id，所以要在 m\_ids 列表中查找，发现 DB\_TRX\_ID 存在列表中，那么这个记录不可见
 *  根据 DB\_ROLL\_PTR 找到 undo log 中的上一版本记录，上一条记录的 DB\_TRX\_ID 还是 101，不可见
 *  继续找上一条 DB\_TRX\_ID为 1，满足 1 < m\_up\_limit\_id，可见，所以事务 103 查询到数据为 name = 菜花

1.  时间点 T6 情况下：

![在这里插入图片描述][44a9c663cc954cc4b77661c28fe38240.png]

`在 RR 级别下只会生成一次Read View，所以此时依然沿用 m_ids ：[101,102]` ，m\_low\_limit\_id为：104，m\_up\_limit\_id为：101，m\_creator\_trx\_id 为：103

*  最新记录的 DB\_TRX\_ID 为 102，m\_up\_limit\_id <= 102 < m\_low\_limit\_id，所以要在 m\_ids 列表中查找，发现 DB\_TRX\_ID 存在列表中，那么这个记录不可见根据 DB\_ROLL\_PTR 找到 undo log 中的上一版本记录，上一条记录的 DB\_TRX\_ID 为 101，不可见
 *  继续根据 DB\_ROLL\_PTR 找到 undo log 中的上一版本记录，上一条记录的 DB\_TRX\_ID 还是 101，不可见
 *  继续找上一条 DB\_TRX\_ID为 1，满足 1 < m\_up\_limit\_id，可见，所以事务 103 查询到数据为 name = 菜花

1.  时间点 T9 情况下：

![在这里插入图片描述][595cb744fac44e34b7df10e0815b8c11.png]

此时情况跟 T6 完全一样，由于已经生成了 Read View，此时依然沿用 m\_ids ：\[101,102\] ，所以查询结果依然是 name = 菜花

***9、MVCC➕Next-key-Lock 防止幻读***

`InnoDB`存储引擎在 `RR` 级别下通过 `MVCC`和 `Next-key Lock` 来解决幻读问题：

**1、执行普通 select，此时会以 MVCC 快照读的方式读取数据**

在快照读的情况下，RR 隔离级别只会在事务开启后的第一次查询生成 Read View ，并使用至事务提交。所以在生成 Read View 之后其它事务所做的更新、插入记录版本对当前事务并不可见，**实现了可重复读和防止快照读下的 “幻读”**

**2、执行 select…for update/lock in share mode、insert、update、delete 等当前读**

在当前读下，读取的都是最新的数据，如果其它事务有插入新的记录，并且刚好在当前事务查询范围内，就会产生幻读！

`InnoDB` 使用 `Next-key Lock` 来防止这种情况。**当执行当前读时，会锁定读取到的记录的同时，锁定它们的间隙，防止其它事务在查询范围内插入数据。只要我不让你插入，就不会发生幻读**

[9dbc6c90547a438b99735cb78a13fb13.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a4fdad2edcba495ea55d1b015c964c3f.png
[efee09598db34beea07b6216121bb921.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d9d3e369efc54f7d8cc2380112e60067.png
[109266dbd4c24e20bc32ce3b41be2ff4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/b5d0184c10c94484a41b7ddc4195dbae.png
[3b44867b13fb4926a545532b146d1ed9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/dc78a3e05e1e429dbf41ed9557866072.png
[a1fe026a799449728e2394d3877d8b38.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c17b63d2e8414f98b48782868a7ad894.png
[92c68cf44c3f40189791f43fb90ac97d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f4346ffd3a474eedb8655c926429729c.png
[695017607eb6434b8944581a485e20e2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/a82e517e7e684c23aae6677513332ea1.png
[8679bb9bade94964bb66b179f4a6f5bb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/9aa3921e1a6a4d2cbcdab80c43b576f9.png
[e5a93db735bc49d78149c2177570d13a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/66186be83fd44879923b7febb477630a.png
[503f9ccf4cab4c55a53dea8be3e4ca3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/398bab20219e40e0a66981fb06a1018d.png
[44a9c663cc954cc4b77661c28fe38240.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/687b600192e2427b93080dc85957935f.png
[595cb744fac44e34b7df10e0815b8c11.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/7086ac6960004d7a99d10cd838ae45fc.png