第 22 章 事务、隔离级别与 MVCC

本章把"并发事务互相看不见"这件事拆到引擎内部的字段级：一行数据的多个历史版本怎么存、读的时候凭什么判定"这个版本我能看"。

学习目标

读完本章，你应当能够：

1. 把 ACID 四条逐一对应到具体机制（undo log / redo log + fsync / 锁 + MVCC / 约束 + 前三者），并说明"一致性不是独立机制"这句话的确切含义；
2. 推导 SQL 标准的四种隔离级别与脏读、不可重复读、幻读三类异常的对应关系，并辨析 InnoDB 与 PostgreSQL 在默认级别上的差异及其原因；
3. 说出 MVCC 的三要素（隐藏字段、undo 版本链、ReadView），画出 undo 版本链的结构图；
4. 按 m_ids / min_trx_id / max_trx_id / creator_trx_id 逐步执行可见性判断算法，并解释"不可见时沿 roll_pointer 回溯"的终止条件；
5. 用"ReadView 的创建时机"解释 RC 与 RR 的全部行为差异，指出"两个级别看的是不同快照数据"这一说法错在哪；
6. 列出快照读与当前读的完整语句清单，举出 RR 下仍然出现幻读的两类具体场景；
7. 定位并量化长事务的三类危害，写出基于 information_schema.innodb_trx 的监控 SQL。

前置知识检查

22.1 ACID 每一条对应哪个机制

“事务有 ACID 四个特性"是本科内容；面试真正在问的是这四条各自靠什么实现、少一个会怎样。把它们对应到机制之后，“一致性（consistency）“的特殊地位就露出来了：它不是某个组件的功能，而是前三者的共同结果，再加上数据库自身的完整性约束。

这里有一个反直觉点必须讲清楚：undo log 同时服务两个完全不同的目的——回滚（原子性）和 MVCC 版本链（隔离性）。同一条 undo 记录，回滚时被"反向执行”，MVCC 时被当作"历史版本读取”。这解释了一个常见困惑：为什么事务提交后 undo 不能立刻删？因为可能还有别的 ReadView 需要读它，必须等 purge 确认没人需要了才回收。purge 的判定条件见 22.7 节。

22.2 四种隔离级别与三类异常：标准与 InnoDB 实际行为的差异

三类异常的定义必须用同一事务内先后两次读的结果来描述，否则说不清区别：

• 脏读（dirty read）：读到了别的事务尚未提交、且可能回滚的修改；
• 不可重复读（non-repeatable read）：同一事务内两次读同一行，值不同（因为中间有别的事务提交了修改）；
• 幻读（phantom read）：同一事务内两次执行同一个范围查询，第二次多出了行（因为中间有别的事务提交了插入）。

标准与实现之所以分叉，原因是 SQL 标准只描述可观察到的现象，不规定实现手段。InnoDB 用 MVCC 提供了一致性读（consistent read），这是一个标准里没有的概念，它顺带把 RR 下的幻读也压掉了。

22.2.1 为什么 PostgreSQL 默认 RC 而 MySQL 默认 RR

这不是口味问题，而是两种 MVCC 实现路线的历史产物：

• MySQL 的默认值来自早期复制格式的约束。binlog_format=STATEMENT 时，从库重放的是 SQL 文本，主库上语句的执行顺序直接决定从库结果，因此主库需要更强的隔离（RR）来压制主从数据不一致；MySQL 8.0 起 binlog_format 默认已是 ROW，这个约束的限制作用已经消失，但默认级别出于兼容性未改。
• PostgreSQL 从 9.1 起默认 RC，因为它的 RC 在每个语句开始时取一次快照，已经能避免语句内部的"半更新状态"，把大部分不可重复读问题留给应用显式处理；这样长事务不会阻塞 vacuum 回收——PostgreSQL 的 VACUUM 与 InnoDB 的 purge 面临同一个问题，降低默认隔离级别是缓解手段之一。

工程上的取舍结论：写多且复制延迟敏感的场景倾向 RC（锁范围小、无间隙锁、主从一致性对 ROW 格式不敏感），需要"整个事务内多次读结果自洽"的报表类场景倾向 RR。MySQL 官方手册在"事务隔离级别"章节给出的实践建议也是把 RC 与 binlog_format=ROW 配对使用。

22.3 MVCC 的三要素：隐藏字段、undo 版本链、ReadView

MVCC（multi-version concurrency control，多版本并发控制）在 InnoDB 里由三个组件协作完成。三者缺一不可：隐藏字段提供定位信息，undo 版本链提供历史数据存储，ReadView 提供可见性规则。

22.3.1 隐藏字段

InnoDB 的聚簇索引记录（COMPACT/DYNAMIC 行格式）除用户列外还有三个隐藏列：

22.3.2 undo 版本链的结构

每次修改一行，InnoDB 把旧版本写进 undo log，并让新记录的 DB_ROLL_PTR 指向它。于是同一行在逻辑上形成一条单向链表，表头是最新版本，越往后越旧。trx_id 标记每个版本由哪个事务产生：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

 表 t 中主键 id = 1 的这一行（当前最新版本在聚簇索引叶子上）

   聚簇索引记录
  ┌──────────────────────────────────────┐
  │ id=1  name='C'  age=30               │
  │ DB_TRX_ID  = 300   ← 谁写了这个版本   │
  │ DB_ROLL_PTR ──────┐                  │
  └───────────────────┼──────────────────┘
                      │ ① 沿回滚指针进入 undo
                      ▼
   undo log（版本链，越深越旧）
  ┌──────────────────────────────────────┐
  │ undo 记录 A：name='B'  age=20        │
  │   trx_id = 200     （由事务 200 写入）│
  │   roll_ptr ───────┐                  │
  └───────────────────┼──────────────────┘
                      │ ② 继续回溯
                      ▼
  ┌──────────────────────────────────────┐
  │ undo 记录 B：name='A'  age=10        │
  │   trx_id = 100     （由事务 100 写入）│
  │   roll_ptr = NULL  （更早没有版本了） │
  └──────────────────────────────────────┘

  版本从新到旧：300 → 200 → 100
  一次可见性判断失败就沿指针走一格，最多走到链尾（NULL）为止

三个必须记住的细节：

1. undo 记录存的是"如何回到上一个版本"，即 update undo 里保存的是被覆盖列的旧值。所以沿链回溯不是"读一份完整快照"，而是"用 undo 逐版本倒推"，这也是长链遍历昂贵的原因。
2. 链的方向与判断顺序相反。可见性判断总是从最新版本开始，一旦命中可见就立刻停止回溯——这是性能上的关键优化，而不是遍历全链再挑。
3. 链的回收由 purge 线程负责，条件是"没有任何活跃 ReadView 还需要比它更旧的版本"（见 22.7 节）。

22.4 ReadView 的四个字段与可见性判断算法

ReadView 是"本事务在创建这一刻，系统里哪些事务还没结束"的名单快照。它只有四个字段：

判断算法的完整流程（每一步都可直接执行）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

 输入：某个版本记录的 DB_TRX_ID（记作 trx_id），当前事务的 ReadView
 输出：该版本对本事务是否可见

 步骤 0  若 trx_id == creator_trx_id
            → 可见（自己改的数据自己一定能看到，与名单无关）
            否则进入步骤 1

 步骤 1  若 trx_id < min_trx_id
            → 可见（这个版本由"名单之前就已结束"的事务产生，一定是已提交的）
            否则进入步骤 2

 步骤 2  若 trx_id ≥ max_trx_id
            → 不可见（这个版本由 ReadView 创建之后才启动的事务产生，必须回滚）
            否则进入步骤 3

 步骤 3  此时 min_trx_id ≤ trx_id < max_trx_id，落在"中间地带"
         在 m_ids 中查找 trx_id：
            找到了   → 不可见（该事务创建 ReadView 时还活跃，可能未提交或已回滚）
            没找到   → 可见（该事务在创建 ReadView 之前已提交，只是 ID 在区间内）

 步骤 4  判为不可见时，沿 DB_ROLL_PTR 取上一个版本，
         把新版本的 trx_id 重新代入步骤 0。
         若指针为 NULL（已到链尾）→ 该行对本事务"不存在"
         （表现为范围查询里这一行不出现，即幻读被压制的来源）

做一个完整算例，把四条规则各命中一次。设当前事务 ID = 300，执行第一条 SELECT 时创建的 ReadView 为 m_ids = {200, 250}，则 min_trx_id = 200、max_trx_id = 301（下一个待分配的 ID）、creator_trx_id = 300。

1
2
3
4
5
6
7
8
9

 版本链： 300 → 250 → 200 → 100 → NULL

 判断 300：等于 creator_trx_id                 → 可见（步骤 0 命中）
 判断 250：200 ≤ 250 < 301，且 250 ∈ m_ids     → 不可见（步骤 3 命中"在名单中"）
 判断 200：200 ≤ 200 < 301，且 200 ∈ m_ids     → 不可见（同上，"小于"不含等于）
 判断 100：100 < min_trx_id = 200              → 可见（步骤 1 命中）

 结论：本事务看到的这一行是 trx_id = 100 产生的那个版本。
       事务 200 与 250 的修改虽然已经写进页里，但都在名单内，一律当作不存在。

22.5 RC 与 RR 的差异根因：ReadView 的创建时机

这是全章最高频的考点，也是最容易答偏的地方。RC 与 RR 的差别只有一处：ReadView 在什么时候创建。 两者的可见性判断步骤 0～4 完全一样。

必须澄清一个非常普遍的误解：这不是"两个级别看到的快照数据不同"，而是"取快照名单的时刻不同"。 存储的数据版本完全一样，undo 链也一样，唯一的区别是"你在什么时刻问系统’现在有哪些事务还活着’"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

 时间轴（同一行 x=1，事务 T1 是 RR，T2/T3 是并发写事务）

 T1: BEGIN ──① SELECT x  ────────────────② SELECT x ──③ SELECT x ── COMMIT
                │                              │            │
                │ 创建 ReadView V1             │ 复用 V1    │ 复用 V1
                │ m_ids={T2}                   │            │
                │                              │            │
 T2:      BEGIN ── UPDATE x=2 ── COMMIT
                                      │
                                      └─ 提交时刻：T1 的 V1 里 T2 在名单中
                                         ⇒ T2 的版本对 T1 永远不可见

 T3:                                        BEGIN ── UPDATE x=3 ── COMMIT
                                                                  │
                                                                  └─ T3 的 ID ≥ V1.max_trx_id
                                                                     ⇒ 同样不可见

 RR 下 ①②③ 全部读到 x=1；RC 下 ② 读到 2、③ 读到 3（因为每次重建名单）

在实际代码里能观察到的差异：同一个 @Transactional 方法内先查一次、业务处理耗时若干秒、再查一次，MySQL 默认 RR 下两次结果一致；如果误配成 RC，第二次可能读到别人刚提交的值，导致"校验通过但更新时数据已经变了"这类偶发故障。这也是用 SELECT ... FOR UPDATE 做悲观锁（见 22.6 节）而不用"先查再改"的原因。

22.6 快照读与当前读：什么时候读的不是历史版本

到 22.5 节为止讲的是快照读（snapshot read）：不加锁，读 ReadView 判定后的历史版本。与它相对的是当前读（current read）：读最新已提交数据，并且会加锁。

SELECT ... FOR UPDATE 的执行语义值得单独说：它先做一次当前读拿到最新提交版本（这一步绕过了 ReadView），然后对匹配的记录加排他锁，并把加锁结果返回。由于它读的是当前数据，读到的行数与内容和快照读可能不同——这就是 RR 下幻读的来源。具体的加锁范围推导（唯一索引等值、非唯一索引等值、范围查询分别加什么锁）归第 24 章 24.3 节，本章只界定"哪些语句会去加锁"。

22.6.1 RR 下仍然出现幻读的两类场景

场景一：当前读本身不属于快照读。 事务 A 中 SELECT * FROM t WHERE id > 100 快照读返回 3 行；事务 B 插入 id = 104 并提交；事务 A 再执行 SELECT * FROM t WHERE id > 100 FOR UPDATE，读到 4 行。原因是第二次是当前读，直接看最新已提交数据，ReadView 完全不参与。同时因为 FOR UPDATE 在 id > 100 的区间上加临键锁（见第 24 章 24.3 节），事务 B 的插入若发生在加锁之后就会被阻塞——加锁能否挡掉幻读，取决于两个事务的先后顺序。

场景二：同一事务内快照读与当前读混用，结果前后矛盾。 这是更隐蔽的一种：

1
2
3
4
5
6
7
8

-- 事务 A（RR 隔离级别，全程未提交）
BEGIN;
SELECT COUNT(*) FROM t WHERE id > 100;          -- 快照读，返回 3：本事务的快照里没有 id=104
-- 此时事务 B 执行 INSERT INTO t VALUES (104, ...) 并 COMMIT

SELECT * FROM t WHERE id > 100 FOR UPDATE;      -- 当前读，返回 4 行：多出来的 id=104 就是幻影行
SELECT COUNT(*) FROM t WHERE id > 100;          -- 又变回 3：复用同一个 ReadView，幻影行再次"消失"
COMMIT;

同一个事务里，同一个条件，一次看到 4 行、一次看到 3 行。这种前后不一致本身就是 RR 隔离级别下的幻读，也是"RR 到底能不能防幻读"这个问题的标准答案落点。要靠当前读做唯一性校验的业务（例如"先 SELECT 判断不存在再 INSERT"），必须意识到两次读的语义不同，正确写法是依赖唯一索引让 INSERT 直接报冲突。

22.7 长事务的三类危害与监控

长事务在面试里的标准答法是"undo 膨胀、回滚慢、锁持有时间长"，但真正把面试官说服的是说清危害的作用链条。这里的机制与 22.4 节的可见性判断直接相连：

1. undo 版本链无法回收，链变长。 purge 线程要回收一个旧版本，前提是"不存在还需要它的 ReadView"。一个开了 10 分钟没提交（甚至只读）的事务，它的 ReadView 一直有效，于是这 10 分钟内产生的所有旧版本都不能删。链一长，22.4 节步骤 4 的回溯次数就线性上涨——危害不是只作用于这个长事务，而是作用于之后所有事务，因为每个新 ReadView 都可能要跨过这些陈旧版本。
2. m_ids 变大，判断落进"中间地带"的行变多。 活跃事务越多，m_ids 越长，二分查找本身代价上升；更严重的是更多版本落进步骤 3 的分支，本来一步能判定的现在要多走几次链。
3. 占用连接与锁。 事务不结束，连接归还不到池子里；写事务持有的行锁要等到提交才释放，innodb_lock_wait_timeout 默认 50 s 一旦打满就是接口大面积超时。此外事务期间 undo 无法清理、崩溃恢复时要回滚的数据量也成倍增长（回滚与崩溃恢复见第 21 章 21.2 节）。

监控 SQL（innodb_trx 里的时间字段是秒，不是微秒，这点常被记错）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- 定位超过 60 秒仍未结束的事务；按持锁行数降序，优先处理真正在写的那些
SELECT trx_id,
       trx_state,                                  -- RUNNING / LOCK WAIT，LOCK WAIT 说明它自己在等锁
       trx_started,                                -- 事务开始时刻，与 NOW() 相减得到已运行时长
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS elapsed_s,
       trx_rows_locked,                            -- 持有或等待的行锁数，量级大说明加锁范围大
       trx_rows_modified,                          -- 已修改行数，直接对应 undo 体积
       trx_is_read_only,                           -- 只读长事务最容易被漏掉，必须单独看这一列
       trx_mysql_thread_id                         -- 需要 kill 时用这个连接 ID
FROM information_schema.innodb_trx
WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 60
ORDER BY trx_rows_locked DESC, elapsed_s DESC;

1
2
3
4
5

-- 从"服务端总览"角度确认是否真的存在陈旧版本积压：History list length 持续上涨即为信号
SHOW ENGINE INNODB STATUS\G
-- 关注输出中的 TRANSACTIONS 段：
--   History list length 12345      ← undo 版本链总长度，长期高位说明 purge 被拖住
--   Purge done for trx's n:o < ... ← purge 推进到的位置，长时间不动就是被长事务卡住

配套的运维手段还有两类：一是把跑批、导数据这类长任务拆成分批提交的小事务（每批 500～1000 行提交一次），把事务时长从"小时级"降到"秒级"；二是给只读报表设置 SET SESSION TRANSACTION READ ONLY（本身不解决 purge 阻塞）与合理的超时，并在应用侧用读超时兜底，而不是让一个 @Transactional 方法包住整段远程调用。

22.8 隔离级别对复制安全性的两个约束

隔离级别不只影响本机并发行为，还通过 binlog 约束主从一致性。这是把第 22 章与第 21、26 章串起来的两道题。

第一道：RC 与 binlog_format = ROW 的配合。 STATEMENT 格式记录的是 SQL 文本，从库重放时会用自己的数据重新执行一遍。RC 下同一个事务内两次读到的数据可能不同（见 22.5 节），主库执行 UPDATE ... WHERE 时依赖的行集合，到从库重放时可能已经变了，于是主从数据分叉。ROW 格式记录的是每行修改前后的镜像，从库不再重新求值，执行顺序与隔离级别都不影响结果，所以 RC 配 ROW 是安全的。MySQL 官方手册因此建议：使用 RC 时把 binlog_format 设为 ROW。反过来，STATEMENT 格式在 RC 下是明确不安全的组合。

第二道：innodb_autoinc_lock_mode 三种模式与主从一致性。

模式 2 与 ROW 格式配合才安全，原因与第一道题完全同源：ROW 格式里自增列的值是随行镜像一起记录的，从库不需要自己再生成，因此不连续也不影响一致性。MySQL 8.0 的默认组合是 innodb_autoinc_lock_mode=2 加 binlog_format=ROW；5.7 的默认是模式 1。这也解释了一个现象：同一张表在批量插入后自增 ID 出现空洞，在模式 2 下是设计使然，不是 bug，也不能靠 AUTO_INCREMENT 重置彻底解决。

本章小结

自测题

Q1（判断）“InnoDB 的 REPEATABLE READ 通过加间隙锁彻底避免了幻读，所以 RR 是不会有幻读的。“请判断并给出准确表述。

Q2（推导）事务 T（ID = 500）第一次 SELECT 时系统活跃事务为 {400, 450}。某行的版本链为 520 → 480 → 450 → 400 → 300 → NULL。请逐步给出每个版本的可见性判定结果，并说明 T 最终读到哪个版本。

1
2
3
4
5

 520：520 ≥ 501                      → 不可见（步骤 2：ReadView 创建后才启动的事务）
 480：400 ≤ 480 < 501，480 ∉ m_ids   → 可见  ← 判断终止
 450：400 ≤ 450 < 501，450 ∈ m_ids   → 不可见
 400：400 ≤ 400 < 501，400 ∈ m_ids   → 不可见（"小于"不含等于，这是边界陷阱）
 300：300 < 400                      → 可见

Q3（辨析）“RC 和 RR 的区别在于：RR 读的是事务开始时的数据快照，RC 读的是最新已提交的数据。“请指出这句话错在哪里，并给出正确表述。

Q4（推导/计算）某核心交易库出现"上午开始响应变慢，下午 P99 从 20 ms 涨到 800 ms，CPU 与磁盘 IO 都不高”。请给出一个基于本章机制的假设、验证 SQL，以及"看到什么数字就确认这个假设"的判据。

Q5（设计）一个"账户余额校验 + 扣减"的接口，业务要求：同一账户的并发扣减不能超扣，且需要记录校验时的余额快照。请分别给出在 RC 和 RR 下的正确实现思路，说明各自为什么成立，并指出只写 SELECT 再 UPDATE 会出什么问题。

面试高频问题与陷阱

延伸阅读

• MySQL 官方手册 InnoDB Locking and Transaction Model 章节，尤其是 “Consistent Nonlocking Reads” 与 “Transaction Isolation Levels” 两节：ReadView 语义、RR 与 RC 的行为差异、binlog_format 与隔离级别的配合建议均以此为准。
• MySQL 官方手册 InnoDB Multi-Versioning 一节：DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID 三个隐藏字段的定义与 undo 版本链的描述。
• MySQL 官方手册 AUTO_INCREMENT Handling in InnoDB 一节：innodb_autoinc_lock_mode 三种模式的定义与各模式对基于语句的复制的影响。
• MySQL 官方手册 information_schema.INNODB_TRX 表：trx_started、trx_rows_locked、trx_rows_modified、trx_is_read_only 等字段的准确口径（时间字段单位是秒）。
• PostgreSQL 官方文档 Transaction Isolation 一章，特别是 “Read Committed Isolation Level” 一节：解释 PG 每个语句取一次快照的语义，可与本章 22.2.1 节对照阅读。
• SQL 标准（ISO/IEC 9075）中的隔离级别与三类现象定义：本章 22.2 节表格中"标准"一列的规范依据，注意标准只描述可观察现象、不规定实现。