MVCC可见性规则是什么

MVCC（Multi-Version Concurrency Control，多版本并发控制）是现代数据库（如 MySQL InnoDB、PostgreSQL、Oracle 等）用来实现高并发读写而不互相阻塞的核心机制。其关键在于：为每个事务提供数据在某个时间点的“快照”，并通过可见性规则判断哪些版本对当前事务可见。

下面以 MySQL InnoDB 为例，系统说明 MVCC 的可见性规则（其他数据库原理类似，但细节略有差异）。

一、MVCC 的核心组成

1. 隐藏字段（每行记录都有）

• DB_TRX_ID：最后一次修改该行的事务 ID
• DB_ROLL_PTR：回滚指针，指向 Undo Log 中的旧版本
• DB_ROW_ID（可选）：行 ID

2. Undo Log

• 保存数据的历史版本
• 用于构造旧快照和回滚

3. ReadView（读视图）

在快照读（普通 SELECT）时生成，包含：

• m_ids：当前活跃（未提交）的事务 ID 列表
• min_trx_id：活跃事务中最小 ID
• max_trx_id：下一个将分配的事务 ID
• creator_trx_id：创建该 ReadView 的事务 ID

二、可见性判断规则（重点）

当某事务读取一行数据时，会按以下规则判断该版本是否可见：

规则 1：当前事务自己修改的，可见 ✅

DB_TRX_ID == creator_trx_id

→ 自己改的，当然能看到

规则 2：修改事务已提交，且早于 ReadView 创建 ✅

DB_TRX_ID < min_trx_id

→ 在 ReadView 创建前就已提交，可见

规则 3：修改事务在当前 ReadView 之后才开启 ❌

DB_TRX_ID >= max_trx_id

→ 当前事务“出生前”的未来事务，不可见

规则 4：修改事务在活跃事务列表中 ❌

min_trx_id <= DB_TRX_ID < max_trx_id
且 DB_TRX_ID 在 m_ids 中

→ 修改数据的事务还没提交，不可见

规则 5：修改事务已提交但仍在活跃列表中 ✅（特殊情况）

DB_TRX_ID 不在 m_ids 中

→ 虽然 ID 在区间内，但已提交，可见

三、版本链回溯过程

如果当前版本不可见：

1. 顺着 DB_ROLL_PTR 找 Undo Log 中的旧版本
2. 对新版本重新执行上述可见性判断
3. 直到找到第一个可见版本或版本链结束

四、不同隔离级别下的行为差异

五、一句话总结

MVCC 可见性规则的本质是：只让事务看到“在它视角下已经提交的数据版本”，并通过事务 ID 和 ReadView 来判断版本是否合法。

如果你愿意，我也可以：

• 用流程图解释
• 对比 PostgreSQL 的 MVCC
• 结合具体 SQL 示例演示可见性判断