约 9 分钟5 张卡

MVCC

MVCC 通过历史版本减少 InnoDB 普通读取与写入之间的阻塞。本文讲解 MySQL 8.0 RC/RR 的版本链与 Read View。内容还包括混合读写的可见性。

1. 面试核心

先记住这几条，再读正文

版本可见性。 MVCC 通过事务信息、undo 历史版本与 Read View 判断可见性。写写冲突仍需要锁。卡 · 行版本与 undo 链
快照建立时机。 RC 每次一致性读创建 Read View。RR 复用首次一致性读的 Read View。WITH CONSISTENT SNAPSHOT 可在 RR 事务启动时建立快照。卡 · RR 的事务级快照
版本链与自身修改。 当前事务自己的修改可见。其他事务的修改若对快照不可见，InnoDB 就沿版本链寻找旧值。卡 · 行版本与 undo 链
快照读与当前读。 RR 的普通 SELECT 使用旧快照。FOR UPDATE 与 UPDATE 使用当前记录。事务自己的修改对后续 SELECT 可见。卡 · 快照读与当前读卡 · 混合读写与新行可见性
长快照成本。 活跃 Read View 需要保留旧版本，会延迟 purge 清理。导出分批提交会切换快照。卡 · 长快照与版本保留

2. 行版本与 undo 链

必会卡 · InnoDB 的 MVCC 和 Read View 如何实现可重复读

InnoDB 为聚簇索引记录保存事务信息。它记录创建或最后修改该版本的事务。回滚指针则关联 undo log 中的旧版本。关键字段是 DB_TRX_ID 和 DB_ROLL_PTR。更新一行时，新值写入当前记录。旧值可以通过 undo 信息重建。

活跃事务都不再需要旧版本后，purge 才能清理相应 undo 记录。长时间持有快照的事务会延迟清理。

3. Read View 与版本可见性

必会卡 · InnoDB 的 MVCC 和 Read View 如何实现可重复读

Read View 会记录创建快照时尚未完成的事务范围。判断一个行版本是否可见时，可以按以下原则理解：

当前事务自己的修改可见。
快照建立前已经提交的事务版本可见。
快照建立时仍活跃的事务版本不可见。
建快照时尚未分配事务 ID 的后续写事务，其版本不可见。

若最新版本不可见，InnoDB 沿 undo 版本链查找更早的版本。找到可见版本或确认记录不存在后，查找才结束。

ReadView::changes_visible 按下面的顺序判断可见性。先单独处理当前事务，再判断其他事务的版本：

条件	可见性
版本事务 ID 等于创建者 `m_creator_trx_id`	自己的修改可见
小于 `m_up_limit_id`	早于活跃事务下界，可见
大于等于 `m_low_limit_id`	超出快照的事务 ID 上界，不可见
位于两个边界之间	在建快照时的活跃读写事务集合 `m_ids` 中则不可见，否则可见

例如创建者为 100，其他活跃事务为 101、103，上界为 105。这时，99 和 102 可见，101 和 105 不可见。101 后来提交也不会修改这张旧视图。字段名中的 up/low 容易与数值上下界的直觉相反。面试时应说明比较关系和活跃集合，避免只背字段名。

4. RC 的语句级快照

在 Read Committed 下，每次普通一致性读都会取得新的 Read View。同一事务内的多次读取也遵循这一规则。若另一事务在两次查询之间提交，后一次查询就能看到新结果。这就是不可重复读。

RC 能更快结束对旧版本的读取需求，并减少部分锁竞争。代价是事务内多次查询不再共享同一个时间点。

5. RR 的事务级快照

必会卡 · InnoDB 的 MVCC 和 Read View 如何实现可重复读卡 · 执行 BEGIN 后，另一个事务提交的修改还能被第一次查询看到吗？

在 Repeatable Read 下，事务的第一次普通一致性读建立快照。后续一致性读继续使用它。因此，其他事务之后提交的新增或修改不会出现在这些快照读中。

START TRANSACTION;
SELECT * FROM orders WHERE id = 100; -- 在这里建立快照

普通 START TRANSACTION 将 Read View 的创建推迟到首次一致性读。若需要立即建立一致快照，在 RR 下可使用 START TRANSACTION WITH CONSISTENT SNAPSHOT。MySQL 8.0 只在 RR 下支持这项快照语义。其他隔离级别会忽略该子句并产生警告。

同一事务自己的写入仍然可见。事务可以既读取旧快照，又修改最新状态。这时，结果会包含自己的新版本和其他行的旧版本。具体例子见混合读写与新行可见性。

6. 快照读与当前读

必会卡 · 同一个 RR 事务里，普通 SELECT 与 FOR UPDATE 为什么可能返回不同值？

RC/RR 下普通 SELECT 使用快照读，从版本链中寻找可见版本。以下操作需要读取当前版本，并参与并发控制：

SELECT ... FOR SHARE、SELECT ... FOR UPDATE、UPDATE 和 DELETE 都属于这类操作。

当前读访问当前记录，并通过锁协调冲突；具体等待规则见 InnoDB 锁。余额扣减业务如果先检查、再修改，就要保护检查结果。业务可使用锁定读、条件更新或其他原子约束。

7. 快照可见性与范围锁

普通一致性读复用同一个 Read View 时，可见范围保持稳定。快照建立后提交的新行，对后续快照查询不可见。

锁定读和写操作会保护记录及间隙，以约束并发插入。具体机制见 InnoDB 锁。

8. 长快照与版本保留

必会卡 · 为什么只读事务也可能让 undo 历史持续增长？

只读事务也能长时间持有旧 Read View。其他事务持续更新时，purge 必须保留该视图所需的 undo 历史。这会增加存储与旧版本读取成本。

批处理、导出和管理脚本应设置运行时限。还应监控活跃事务的持续时间与 undo 历史。允许跨批次看到新数据时可以分批提交；若全量导出必须来自同一快照，就要避免分批提交。此时应控制快照持续时间与负载，或使用专门的备份方案。不要让一个无人关注的会话长期保持事务打开。

9. 双会话可见性推演

必会卡 · 执行 BEGIN 后，另一个事务提交的修改还能被第一次查询看到吗？卡 · 同一个 RR 事务里，普通 SELECT 与 FOR UPDATE 为什么可能返回不同值？卡 · RR 事务更新另一事务新插入的行后，为什么普通 SELECT 能看到它？

先创建独立的练习表：

CREATE TABLE mvcc_demo (id INT PRIMARY KEY, amount INT) ENGINE=InnoDB;
INSERT INTO mvcc_demo VALUES (1, 100);

以下步骤按表格从上到下执行，B 使用默认自动提交，A 显式设为 RR：

步骤	会话 A	会话 B	A 的读取结果
1	`SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION;`	—	尚未创建普通一致性读快照
2	—	`UPDATE mvcc_demo SET amount=110 WHERE id=1;`	—
3	`SELECT amount FROM mvcc_demo WHERE id=1;`	—	110，首次一致性读建立快照
4	—	`UPDATE mvcc_demo SET amount=120 WHERE id=1;`	—
5	再执行第 3 步查询	—	仍为 110
6	`SELECT amount FROM mvcc_demo WHERE id=1 FOR UPDATE;`	—	120，锁定读访问当前已提交记录
7	`COMMIT;` 后再次普通查询	—	120，旧事务已结束

若 A 改为 RC，第 5 步会读到 120。第 6 步不会把 RR 原有 Read View 更新成新快照；当前读可以看到新值，后续普通查询仍可读取旧快照。

再考虑快照建立时，一个修改事务尚未提交。即使它稍后提交，RR 也不会把该版本纳入旧 Read View。可见性判断依据建快照时的事务状态。

9.1 混合读写与新行可见性

另一事务在快照后插入的行，可以被 RR 事务更新。更新后，普通 SELECT 可以看到自己生成的新版本。使用前述 mvcc_demo，先确保表中只有 (1, 100)。两个会话均须结束上一轮事务，B 使用自动提交：

步骤	会话 A（RR）	会话 B	A 的结果
1	`START TRANSACTION; SELECT * FROM mvcc_demo WHERE id >= 2;`	—	空，建立快照
2	—	`INSERT INTO mvcc_demo VALUES (2, 200);`	B 提交新行
3	`SELECT * FROM mvcc_demo WHERE id >= 2;`	—	仍为空
4	`UPDATE mvcc_demo SET amount=amount+1 WHERE id=2;`	—	影响 1 行
5	`SELECT * FROM mvcc_demo WHERE id >= 2;`	—	返回 `(2, 201)`
6	`ROLLBACK;`	—	撤销 A 的更新，B 插入的行仍保留