3.1 InnoDB 的版本链结构#

MVCC 为每行数据维护一条版本链，每个版本包含事务 ID 和指向旧版本的指针。InnoDB 的每行数据在聚簇索引的记录头中隐藏了三个字段：

• DB_TRX_ID：最后修改该行的事务 ID
• DB_ROLL_PTR：指向 Undo Log 中该行的上一版本
• DB_ROW_ID：没有主键时 InnoDB 自动生成的行 ID

修改数据时，旧版本被写入 Undo Log，新版本留在数据页中，通过 DB_ROLL_PTR 串联成链：

数据页中只存最新版本，旧版本全部在 Undo Log 中。读操作如果发现最新版本不可见，就沿 roll_ptr 回溯，直到找到可见版本。

3.2 PostgreSQL 的版本链对比#

PostgreSQL 的 MVCC 实现截然不同。它采用 Append-Only 方案，每行数据包含 xmin（插入该行的事务 ID）和 xmax（删除/更新该行的事务 ID，初始为 0）。更新操作不是就地修改，而是插入新行并标记旧行的 xmax。

4.1 ReadView 的结构#

MVCC 的算法核心是可见性判断：给定一个 ReadView（快照），判断版本链上的哪个版本对当前事务可见。InnoDB 的 ReadView 包含四个关键字段：

• m_ids：生成 ReadView 时所有活跃（未提交）事务的 ID 列表
• min_trx_id：m_ids 中的最小值
• max_trx_id：下一个将分配的事务 ID（即当前最大事务 ID + 1）
• creator_trx_id：创建该 ReadView 的事务 ID

4.2 可见性判断规则#

从版本链最新版本开始，沿 roll_ptr 回溯，对每个版本的 trx_id 执行以下判断：

1. trx_id == creator_trx_id，可见。这是当前事务自己修改的版本。
2. trx_id < min_trx_id，可见。该版本在 ReadView 创建前已提交。
3. trx_id >= max_trx_id，不可见。该版本在 ReadView 创建后才开始。
4. trx_id 在 m_ids 列表中，不可见。该版本对应的事务在 ReadView 创建时还活跃未提交。
5. trx_id 不在 m_ids 列表中，可见。该版本对应的事务在 ReadView 创建前已提交。

如果一个版本不可见，就沿 roll_ptr 找上一个版本，重复上述判断，直到找到可见版本或版本链到底。

4.3 可见性判断实例#

假设有版本链 V3（trx_id=103）、V2（trx_id=102）、V1（trx_id=101），当前 ReadView 的 min_trx_id=102、max_trx_id=104、m_ids={102, 103}：

事务 102 和 103 都在活跃列表中，它们的修改不可见，读操作最终落到 V1（trx_id=101，在 ReadView 创建前已提交）。

6.1 长事务与 Undo 膨胀#

MVCC 的代价是旧版本不能立即删除。只要还有事务的 ReadView 可能需要某个版本，该版本就必须保留在 Undo Log 中。长事务持有 ReadView 的时间越长，Undo Log 中积累的旧版本就越多，这就是 Undo 段膨胀。

Undo 膨胀的直接危害是磁盘空间被占用，间接危害是版本链变长，快照读需要回溯更多版本才能找到可见数据，查询性能下降。

6.2 Undo 表空间管理#

MySQL 8.0 默认使用独立 Undo 表空间（innodb_undo_tablespaces），可以用 innodb_undo_log_truncate 控制自动截断：

排查 Undo 膨胀的常用命令：

1
-- 查看 Undo 表空间状态
2
SELECT SPACE, NAME AS tablespace_name, SPACE_TYPE, STATE, FILE_SIZE, ALLOCATED_SIZE
3
FROM information_schema.INNODB_TABLESPACES
4
WHERE SPACE_TYPE = 'Undo';
5

6
-- 查看活跃的最旧事务（持有最旧 ReadView 的事务）
7
SELECT trx_id, trx_started, trx_state, trx_query
8
FROM information_schema.INNODB_TRX
9
ORDER BY trx_started ASC LIMIT 5;

trx_started 时间最早的事务，很可能就是持有最旧 ReadView、阻止 Undo 清理的元凶。Kill 掉它之后，Purge 线程会开始清理积累的旧版本。

7.1 为什么需要 SSI#

事务原理与隔离级别 中提到，SERIALIZABLE 通过 S2PL 实现时性能很差：所有读操作加共享锁，直到事务提交才释放，并发度极低。SSI（Serializable Snapshot Isolation）提供了另一种思路：在 MVCC 快照隔离的基础上，检测写偏序冲突，只回滚真正产生冲突的事务。

7.2 写偏序的必要条件#

写偏序的必要条件是两个事务之间存在 rw（读-写）冲突：事务 T1 读了某数据，事务 T2 写了该数据。如果两个并发事务之间存在双向 rw 冲突，就可能产生写偏序。

假设两个事务的操作如下：

• 事务 T1：读取 X，然后写入 Y
• 事务 T2：读取 Y，然后写入 X

分析冲突关系：

• T1 读 X 与 T2 写 X 构成 rw 冲突
• T2 读 Y 与 T1 写 Y 构成 rw 冲突
• 双向 rw 冲突 → 可能写偏序 → 回滚其中一个

SSI 的关键观察是：单方向的 rw 冲突不构成写偏序，只有双向 rw 冲突才需要处理。大多数 OLTP 事务之间不存在双向 rw 冲突，因此 SSI 的回滚率远低于 S2PL 的阻塞率。

7.3 PostgreSQL 的 SSI 实现#

PostgreSQL 从 9.1 版本开始支持 SSI，是第一个在生产数据库中实现 SSI 的系统。其实现基于以下机制：

1. SI（快照隔离）：每个事务看到一致的快照，读不阻塞写
2. rw 冲突追踪：记录事务之间的读写依赖关系
3. 危险结构检测：检测两个 rw 冲突形成的三事务环
4. 回滚决策：选择代价最小的事务回滚

1
-- PostgreSQL SSI 示例
2
SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE;
3

4
-- 事务 T1
5
BEGIN;
6
SELECT COUNT(*) FROM on_call WHERE on_duty = true;  -- 返回 2
7
-- SSI 记录：T1 读取了 on_call 表中 on_duty=true 的行
8

9
-- 事务 T2（并发）
10
BEGIN;
11
SELECT COUNT(*) FROM on_call WHERE on_duty = true;  -- 返回 2
12
UPDATE on_call SET on_duty = false WHERE doctor = 'Bob';
13
-- SSI 记录：T2 写入了 T1 读取的行 → rw 冲突
14

15
-- 事务 T1
16
UPDATE on_call SET on_duty = false WHERE doctor = 'Alice';
17
-- SSI 检测到双向 rw 冲突 → 回滚 T1
18
-- ERROR: could not serialize access due to read/write dependencies

7.4 SSI 与 S2PL 对比#

SSI 的优势在于只读事务永远不会被阻塞或回滚。在大多数 OLTP 场景中，读写冲突并不频繁，SSI 的回滚率远低于 S2PL 的阻塞率。