InnoDB MVCC 核心原理 逐层深度拆解

我会严格按照从根源到实现、从基础到核心的逻辑逐层拆解，先解决「有锁为什么还要 MVCC」的本质问题，再依次拆解快照读 / 当前读、版本链、ReadView，最终形成完整的 MVCC 闭环逻辑，全程贴合 InnoDB MySQL 8.0 的官方实现。

第一层：核心根源 —— 有锁机制，为什么还要引入 MVCC？

要理解 MVCC，必须先搞懂锁机制的核心痛点，以及 MVCC 要解决的本质问题。

1. 锁机制的本质与局限

InnoDB 的锁是悲观并发控制（PCC） 的核心实现，核心逻辑是「先加锁，再操作」，解决的是并发事务的写写冲突、脏写等核心一致性问题，但存在无法规避的致命短板：

• 读写互斥，并发性能瓶颈：写操作会加排他锁（X 锁），一旦加锁，其他事务的读、写操作全被阻塞；读操作加共享锁（S 锁）时，其他事务的写操作也会被阻塞。对于互联网绝大多数读多写少的业务场景，大量读请求会被写操作阻塞，数据库吞吐量会急剧下降。
• 
  
• 额外的系统开销：频繁的锁竞争、锁等待会导致线程上下文频繁切换，增加系统 CPU 开销；同时多事务交叉加锁还会带来死锁风险。
• 
  
• 用户体验差：读写互斥会导致前端查询请求超时、卡顿，无法满足高并发场景的低延迟要求。

2. MVCC 的核心价值 —— 与锁互补，而非替代

MVCC 全称多版本并发控制（Multi-Version Concurrency Control），是乐观并发控制的经典实现，核心设计目标是：在不加锁的前提下，解决读写冲突问题，实现读写不阻塞。

• 读操作（快照读）全程不加锁，不会被写操作阻塞，也不会阻塞写操作，读并发性能提升数个量级；
• 
  
• 写写冲突依然靠锁机制解决（两个事务同时修改同一行数据，必须互斥），MVCC 不替代锁，而是和锁形成互补，共同实现 InnoDB 的高性能并发控制。
• 
  
• 额外收益：基于 MVCC 实现了READ COMMITTED（读已提交）和REPEATABLE READ（可重复读，InnoDB 默认）两大事务隔离级别，无需靠加锁就能实现隔离性，大幅降低了隔离级别的性能开销。

一句话总结：锁解决了「数据一致性」的底线问题，MVCC 解决了「高并发读场景下的性能」问题，二者缺一不可。

第二层：MVCC 的前置概念 —— 快照读 & 当前读

MVCC 只对快照读生效，当前读依然靠锁机制实现，二者是 InnoDB 并发控制的两条核心路径，必须先明确边界。

1. 快照读（Snapshot Read）

又称一致性非锁定读，是 MVCC 的核心载体，读取的是数据的历史快照版本，全程不加锁，不会阻塞任何写操作。

• 触发场景：普通的不加锁 SELECT 语句，例如：

• 前提限制：仅在READ COMMITTED和REPEATABLE READ两个隔离级别下生效；SERIALIZABLE隔离级别下，所有普通 SELECT 都会自动加共享锁，退化为当前读。

2. 当前读（Current Read）

又称锁定读，读取的是数据的最新提交版本，会对读取的记录加锁，保证读取到的是当前绝对最新的数据，会阻塞其他事务的冲突写操作。

触发场景：所有加锁读、写操作，包括：

核心逻辑：写操作（UPDATE/DELETE/INSERT）执行时，会先对目标行执行当前读，加排他锁，再执行修改，这也是为什么写写冲突必须靠锁解决的原因。

第三层：MVCC 的底层基础 —— 行隐藏列 & 版本链

MVCC 的核心是「多版本」，而多版本的载体就是版本链，版本链的构建依赖 InnoDB 聚簇索引行记录的 3 个隐藏列。

1. InnoDB 行记录的 3 个核心隐藏列

InnoDB 的聚簇索引中，每一行记录除了我们自定义的业务列，还会自动生成 3 个隐藏列，是 MVCC 和事务管理的基石：

2. 版本链的生成逻辑（带实例，逐层拆解）

版本链的本质是：通过 DB_ROLL_PTR 回滚指针，将同一行记录的所有历史版本串联起来的单向链表，链表的头节点是该行记录的最新版本，尾节点是最早的历史版本。

我们用一个完整的实例，拆解版本链的生成全过程：

初始步骤：事务 100 插入数据

事务 ID=100，执行插入语句，提交事务

此时该行记录的核心字段：

因为是首次插入，没有历史版本，DB_ROLL_PTR 为 NULL，版本链只有一个节点。

步骤 2：事务 200 修改数据

事务 ID=200，执行更新语句，未提交：

InnoDB 的执行流程：

1. 对该行记录加排他锁；
2. 将修改前的旧版本（name=' 张三 '，DB_TRX_ID=100）完整写入 undo log；
3. 修改当前行的 name 为 ' 李四 '，更新 DB_TRX_ID 为当前事务 ID=200；
4. 更新 DB_ROLL_PTR，指向刚才写入的 undo log 地址（也就是事务 100 生成的旧版本）。

此时版本链：最新版本（李四，trx_id=200） → 历史版本1（张三，trx_id=100） → NULL

步骤 3：事务 300 再次修改数据

事务 ID=300，执行更新语句，提交事务：

重复上述流程：将事务 200 的版本（李四，trx_id=200）写入 undo log，更新当前行 name=' 王五 '，DB_TRX_ID=300，DB_ROLL_PTR 指向事务 200 的版本。

此时最终版本链：最新版本（王五，trx_id=300） → 历史版本1（李四，trx_id=200） → 历史版本2（张三，trx_id=100） → NULL

3. 版本链的关键补充规则

1. DELETE 操作是逻辑删除：执行 DELETE 时，不会直接物理删除行记录，只会将行记录的删除标记位（delete flag）置为 1，同时生成 undo log 加入版本链；只有当 purge 线程判断没有任何事务需要该历史版本时，才会物理删除。
2. undo log 的生命周期：INSERT 操作的 undo log，事务提交后即可被清理（仅回滚时需要）；UPDATE/DELETE 的 undo log，必须等没有任何 ReadView 依赖该版本时，才会被 purge 线程清理，否则会导致快照读找不到历史版本。
3. 版本链的可见性：版本链存储了所有历史版本，但不是所有版本都对当前事务可见，哪个版本可见，由 ReadView 的可见性规则决定。

第四层：MVCC 的核心大脑 ——ReadView 结构与工作原理

ReadView（读视图）是 MVCC 的核心，是事务执行快照读时生成的「一致性视图」，它定义了当前事务能看到哪些数据版本，是解决脏读、不可重复读、幻读的核心机制。

1. ReadView 的核心结构（4 个关键字段，缺一不可）

ReadView 本质是一个数据结构，包含 4 个核心字段，每个字段都直接决定版本的可见性：

2. 版本可见性判断核心规则（按优先级排序，逐层判断）

快照读时，会从版本链的头节点（最新版本）开始，依次按照以下规则判断版本是否对当前事务可见，

只要满足一条规则，就停止判断，得出最终结果。我们将待判断版本的事务 ID 记为trx_id（即该版本的DB_TRX_ID），判断步骤如下：

步骤 1：判断是否是当前事务自己修改的版本

规则：如果 trx_id == creator_trx_id → 该版本可见。解释：自己修改的数据，自己当然可以看到，无论事务是否提交。

步骤 2：判断版本是否在 ReadView 生成前就已提交

规则：如果 trx_id < min_trx_id → 该版本可见。解释：该版本的事务 ID，比当前所有活跃事务的最小 ID 还小，说明这个事务在 ReadView 生成的时候，已经提交完成，所以它修改的版本对当前事务可见。

步骤 3：判断版本是否在 ReadView 生成后才启动

规则：如果 trx_id >= max_trx_id → 该版本不可见。解释：该版本的事务 ID，比 ReadView 生成时的下一个待分配 ID 还大，说明这个事务是在

ReadView 生成之后才启动的，它修改的版本对当前事务不可见。

步骤 4：判断版本对应的事务是否是活跃事务

前提：trx_id 落在 [min_trx_id, max_trx_id) 区间内，需要进一步判断。规则 1：如果 trx_id 在 m_ids 列表中 → 该版本不可见。说明生成

ReadView 时，这个事务还是活跃未提交的，它的修改不能被看到。规则 2：如果 trx_id 不在 m_ids 列表中 → 该版本可见。说明生成 ReadView 时，这个事务已经提交了，它的修改可以被看到。

不可见版本的处理逻辑

如果当前版本不可见，就顺着DB_ROLL_PTR指针，找到版本链的上一个历史版本，重复上述 4 步判断，直到找到第一个可见的版本，返回该版本的数据；如果遍历到版本链末尾都没有找到可见版本，就返回空。

3. 可见性规则实例演示（快速理解）

假设当前事务 A 的事务 ID=103，生成 ReadView 时：

• 数据库中活跃的事务 ID：101、103、105 → m_ids = [101,103,105]
• min_trx_id = 101
• max_trx_id = 106（下一个待分配的事务 ID 是 106）
• creator_trx_id = 103

我们对多个版本做可见性判断：

第五层：隔离级别的核心实现 ——ReadView 的生成时机差异

InnoDB 的READ COMMITTED（RC）和REPEATABLE READ（RR）两大隔离级别，底层都是靠 MVCC 实现，核心差异就是 ReadView 的生成时机不同，这也是面试的核心考点。

1. READ COMMITTED（读已提交）级别

生成规则：事务中每一次执行快照读，都会重新生成一个全新的 ReadView。

核心效果

每次 SELECT 都会获取当前数据库最新的活跃事务状态，生成新的 ReadView。只要其他事务在两次 SELECT 之间提交了修改，新的 ReadView 就会感知到，从而看到最新提交的版本。

• 解决了脏读：永远不会看到未提交的事务修改（因为未提交的事务 ID 一定在 m_ids 中，不可见）；
• 存在不可重复读：同一个事务内，两次相同的 SELECT，可能返回不同的结果（因为中间有其他事务提交了修改，新的 ReadView 看到了新版本）。

2. REPEATABLE READ（可重复读，InnoDB 默认）级别

生成规则：事务中第一次执行快照读时，生成一个 ReadView，整个事务生命周期内，所有快照读都复用这个 ReadView。

核心效果

整个事务内，所有快照读都基于同一个 ReadView 做可见性判断，无论其他事务是否提交修改、什么时候提交，都不会改变可见性结果，从而保证了同一个事务内，多次相同 SELECT 的结果完全一致。

• 解决了脏读、不可重复读；
• 配合 Next-Key Lock（临键锁），彻底解决了幻读问题：快照读靠复用 ReadView 保证结果集不变，当前读靠临键锁锁住范围，防止其他事务插入新数据。

3. 两种隔离级别的实例对比

我们用一个完整的时间线，直观展示差异：

初始数据

id=1，name=' 张三 '，DB_TRX_ID=100，已提交。

RC 级别执行结果

• T3：第一次 SELECT，生成 ReadView，m_ids=[200]，事务 300 已提交（不在 m_ids 中），看到name='李四'；
• T5：第二次 SELECT，重新生成 ReadView，m_ids=[200]，事务 400 已提交（不在 m_ids 中），看到name='王五'；
• 结果：两次 SELECT 结果不同，出现不可重复读，符合 RC 级别特性。

RR 级别执行结果

• T3：第一次 SELECT，生成 ReadView，m_ids=[200]，max_trx_id=400，事务 300 已提交，看到name='李四'；
• T5：第二次 SELECT，复用 T3 生成的 ReadView，事务 400 的 trx_id=400 >= max_trx_id=400，不可见，依然看到name='李四'；
• 结果：两次 SELECT 结果完全一致，实现了可重复读，符合 RR 级别特性。

第六层：完整闭环 ——MVCC 快照读的全流程执行步骤

最后，我们把前面所有知识点串联起来，还原一个 RR 级别下，快照读的完整执行流程，形成完整的知识闭环：

1. 事务启动：客户端开启事务，此时不会分配事务 ID，也不会生成 ReadView。
2. 首次快照读触发 ReadView 生成：事务第一次执行普通 SELECT 语句，InnoDB 为该事务生成一个全局唯一的 ReadView，记录当前的m_ids、min_trx_id、max_trx_id、creator_trx_id，整个事务后续的快照读都复用这个 ReadView。
3. 定位行记录：InnoDB 通过聚簇索引，找到 SELECT 语句匹配的行记录。
4. 版本链可见性判断：拿到该行记录的最新版本，获取DB_TRX_ID，按照 ReadView 的 4 步可见性规则，判断该版本是否可见。
5. 版本链遍历：如果当前版本不可见，就顺着DB_ROLL_PTR回滚指针，找到版本链的上一个历史版本，重复步骤 4 的可见性判断。
6. 结果返回：找到第一个对当前事务可见的版本，提取该版本的业务列数据，返回给客户端；如果遍历完版本链都没有找到可见版本，返回空。
7. 后续快照读复用：事务后续执行的所有普通 SELECT，都直接复用第一次生成的 ReadView，重复步骤 3-6，保证可重复读

核心补充知识点

1. 二级索引的 MVCC 实现：二级索引页中没有DB_TRX_ID和DB_ROLL_PTR，InnoDB 通过「索引页最大事务 ID」做快速判断：如果索引页的最大事务 ID < ReadView 的min_trx_id，说明该页所有数据都可见，直接读取二级索引；否则需要回表到聚簇索引，通过版本链和 ReadView 判断可见性。
2. undo log 的 purge 机制：purge 线程会定期扫描 undo log，判断该 undo log 对应的版本，是否早于当前系统中最老的 ReadView，如果是，说明没有任何事务需要该版本，就会清理该 undo log，释放磁盘空间。
3. 只读事务优化：InnoDB 对只读事务做了优化，不会分配事务 ID，也不会生成 ReadView，大幅降低了只读事务的开销，提升了高并发读场景的性能