MySQL 的 MVCC（多版本并发控制）详解-平芜编程栈

MVCC（Multi-Version Concurrency Control，多版本并发控制）是 MySQL InnoDB 存储引擎实现事务隔离级别的核心机制，其核心目标是在不加锁（或减少加锁）的情况下，实现读写并发，同时保证事务的隔离性，避免脏读、不可重复读等问题，大幅提升数据库的并发性能。

一、MVCC 的核心思想

MVCC 为每行数据维护多个版本（快照），不同事务在访问同一行数据时，会根据自身的 “视图” 看到不同版本的数据：

读操作（SELECT）：无需加锁，直接读取符合事务版本的快照，避免与写操作互斥；
写操作（INSERT/UPDATE/DELETE）：不修改原数据，而是创建数据的新版本，旧版本保留（由 undo log 维护），供其他事务读取。

简单来说：写操作创建新版本，读操作读取历史版本，读写互不阻塞。

二、MVCC 的核心依赖组件

InnoDB 实现 MVCC 依赖以下关键数据结构和日志，缺一不可：

2.1 行记录的隐藏列

InnoDB 为每张表的每行数据默认添加 3 个隐藏列（用户不可见），用于版本管理：

隐藏列	作用	数据类型
DB_TRX_ID	最后一次修改该行数据的事务 ID（插入 / 更新），删除视为 “更新”（标记删除）	6 字节
DB_ROLL_PTR	回滚指针，指向 undo log 中该记录的历史版本（形成版本链）	7 字节
DB_ROW_ID	行 ID（聚簇索引的默认主键，仅当表无主键 / 唯一索引时生成）	6 字节

2.2 Undo Log（回滚日志）

作用：
保存数据的历史版本（每次修改行数据时，先将旧版本写入 undo log）；
事务回滚时，通过 undo log 恢复数据；
为 MVCC 提供历史版本数据。
版本链：每行数据的DB_ROLL_PTR指向 undo log 中该记录的上一个版本，所有版本通过回滚指针串联成版本链（头节点是最新版本）。
类型：
INSERT_UNDO：记录插入操作的 undo 日志（事务提交后可直接删除，因为插入的行仅当前事务可见）；
UPDATE_UNDO：记录更新 / 删除操作的 undo 日志（需保留至所有依赖该版本的事务结束）。

2.3 Read View（读视图）

Read View 是事务在执行快照读（普通 SELECT）时生成的可见性判断规则，决定了当前事务能看到哪些版本的数据。
Read View 的核心属性

属性	含义
m_ids	当前活跃（未提交）的事务 ID 列表
min_trx_id	m_ids中的最小事务 ID
max_trx_id	系统下一个要分配的事务 ID（即当前最大事务 ID+1）
creator_trx_id	创建该 Read View 的事务 ID

可见性判断规则
对于版本链中的某行数据版本（记其事务 ID 为trx_id），判断是否对当前事务可见：

如果 trx_id < min_trx_id：该版本由已提交的事务创建，可见；
如果 trx_id >= max_trx_id：该版本由未来的事务创建，不可见；
如果 min_trx_id ≤ trx_id < max_trx_id：

若trx_id在m_ids中（事务未提交），不可见；
若trx_id不在m_ids中（事务已提交），可见；

特殊：如果trx_id = creator_trx_id（当前事务自己修改的数据），可见。

2.4 事务 ID（Trx ID）

InnoDB 为每个事务分配唯一的递增事务 ID；
事务开始时不一定分配 ID，仅当执行写操作（INSERT/UPDATE/DELETE）时才分配；
只读事务（仅 SELECT）可能不分配 ID，进一步提升性能。

三、MVCC 的工作流程（以可重复读为例）

MySQL 默认隔离级别是REPEATABLE READ（可重复读），MVCC 在该级别下的核心行为是：事务在第一次快照读时生成 Read View，后续所有快照读复用该 Read View。
示例：两个事务并发操作同一行数据
假设初始数据：表user有一行数据id=1, name=‘Tom’，其DB_TRX_ID=100（初始事务 ID）。

时间	事务 A（读）	事务 B（写）
T1	开始事务	开始事务
T2	1.执行SELECT * FROM user WHERE id=1;（第一次快照读）2.生成 Read View：m_ids=[200]（事务 B 的 ID）、min_trx_id=200、max_trx_id=201、creator_trx_id=199 3.读取行版本trx_id=100 < 200，可见，结果：Tom	-
T3	-	1.执行UPDATE user SET name=‘Jerry’ WHERE id=1; 2.分配事务 ID=200 3.旧版本（trx_id=100）写入 undo log 4.新版本数据：name=‘Jerry’，DB_TRX_ID=200，DB_ROLL_PTR指向旧版本
T4	1.再次执行SELECT * FROM user WHERE id=1; 2.复用 T2 的 Read View 3.新版本trx_id=200在m_ids中，不可见 4.沿着版本链找旧版本trx_id=100，可见 5.结果仍为Tom（可重复读）	-
T5	-	提交事务 B
T6	1.第三次执行SELECT * FROM user WHERE id=1; 2.仍复用 T2 的 Read View 3.事务 B 已提交，但m_ids仍为[200]（Read View 不更新） 4.结果还是Tom	-
T7	提交事务 A	-
T8	新事务 C	1.执行SELECT * FROM user WHERE id=1; 2.生成新 Read View：m_ids=[]、min_trx_id=201、max_trx_id=202 3.新版本trx_id=200 < 201，可见，结果：Jerry

关键结论：

事务 A 在整个生命周期内，无论事务 B 是否提交，都只能看到第一次快照读时的版本（可重复读）；
新事务 C 在事务 B 提交后，能看到最新版本；
全程无锁，读写互不阻塞。

四、MVCC 在不同隔离级别的表现

MVCC 的行为随隔离级别不同而变化，核心差异在于Read View 的生成时机：

隔离级别	Read View 生成时机	核心行为	解决的问题
READ UNCOMMITTED（读未提交）	不生成 Read View，直接读取最新版本	能看到未提交事务的修改（脏读）	无（几乎不用）
READ COMMITTED（读已提交）	每次快照读都生成新的 Read View	每次读都能看到已提交的最新版本（不可重复读）	脏读
REPEATABLE READ（可重复读）	第一次快照读生成 Read View，后续复用	事务内多次读结果一致（可重复读）	脏读、不可重复读
SERIALIZABLE（串行化）	不依赖 MVCC，直接加锁（间隙锁 / 行锁）	读写互斥，完全串行	所有并发问题（性能差）

五、MVCC 的两种读操作

InnoDB 中读操作分为两类，只有快照读依赖 MVCC：

快照读（Snapshot Read）

定义：读取数据的历史版本，不加锁，依赖 MVCC；
场景：普通 SELECT（无 FOR UPDATE/LOCK IN SHARE MODE）；
特点：读写不阻塞，性能高。

当前读（Current Read）

定义：读取数据的最新版本，且会加锁（行锁 / 间隙锁），不依赖 MVCC；
场景：
SELECT … FOR UPDATE（排他锁）；
SELECT … LOCK IN SHARE MODE（共享锁）；
INSERT/UPDATE/DELETE（隐式当前读，先读最新版本再修改）；
特点：保证读取的是最新版本，会阻塞其他写操作，或被其他写操作阻塞。

六、MVCC 的优势与局限性

优势

读写并发：读不阻塞写，写不阻塞读（快照读），大幅提升高并发场景性能；
隔离性保证：通过版本链和 Read View，精准控制事务可见性，实现不同隔离级别；
无锁读：快照读无需加锁，避免锁竞争和死锁；
事务回滚高效：通过 undo log 快速回滚，无需重做整个操作。
局限性
版本链膨胀：大量更新操作会导致 undo log 版本链过长，快照读时需要遍历版本链，性能下降；
undo log 清理：InnoDB 需要判断哪些 undo log 版本已无事务依赖，清理不及时会占用磁盘空间；
幻读问题（可重复读下）：
MVCC 解决了 “不可重复读”，但未完全解决 “幻读”（例如：事务 A 第一次读 10 行，事务 B 插入 1 行并提交，事务 A 用当前读（如SELECT … FOR UPDATE）会读到 11 行）；
InnoDB 通过间隙锁（Next-Key Lock）补充解决幻读（仅可重复读级别）。