第 21 章 Redo Log、undo Log 与 Binlog

三种日志是 InnoDB 的一切承诺（不丢、可回滚、可复制）的物质基础；两阶段提交则是它们之间唯一的粘合剂。

学习目标

读完本章，你应当能够：

1. 从"顺序写 vs 随机写"与"日志是紧凑表示"两条理由推导出 WAL 的收益，并据此判断 innodb_flush_log_at_trx_commit 三种取值在进程崩溃与机器断电下各自的丢失窗口；
2. 说清 redo log 为什么是物理逻辑日志，画出 write pos/checkpoint 的环形结构，推导"日志写满"时为什么会导致写入停顿；
3. 画出组提交（group commit）三个阶段的队列模型，解释 binlog_group_commit_sync_delay 如何用延迟换吞吐，以及它与 sync_binlog/innodb_flush_log_at_trx_commit 的耦合关系；
4. 区分 insert undo 与 update undo 在提交后能否立即删除，说明 purge 线程、长事务与 undo 表空间膨胀的因果链；
5. 对两阶段提交的三种崩溃时机逐个给出恢复结果，解释为什么决断依据必须是"redo 是 prepare 状态且 binlog 完整"，并按 checkpoint → 重放 redo → 处理 prepare → 用 binlog 决断 → 回滚未提交 的顺序复述崩溃恢复流程，说出 innodb_force_recovery 各级的含义。

前置知识检查

21.1 WAL：为什么"先写日志再写数据"更快也更安全

21.1.1 两条理由：顺序写与紧凑表示

WAL（Write-Ahead Logging）的规则只有一句：修改数据页之前，必须先把这次修改的日志刷到持久存储。它同时解决两个独立问题。

第一是性能。数据页散落在表空间的各个位置，一次事务可能改 5 个页，这 5 个页在磁盘上的物理位置毫无规律；而 redo log 是追加写（append-only），从头顺到尾。机械盘上一次随机写要等寻道 + 旋转（约 5~10 ms），一次顺序写只需付出传输时间；即使在 SSD 上，随机写 4 KB 约 100 μs，而顺序写带宽可以跑满接口。更关键的是合并：同一页被改 100 次，redo 里就有 100 条记录，而刷脏页只写 1 次磁盘——把"随机写"转成"顺序写 + 批量合并"。

第二是安全。提交时若必须把数据页本身刷盘，一次事务要等待所有涉及页的随机写完成，且部分页写成功、部分失败会留下物理上不一致的页（这也是 innodb_doublewrite 存在的原因之一）。而只要日志落盘，内存里的数据页可以随便延迟写——崩溃后用日志重放即可重建。

还有第三个常被忽略的点：日志是紧凑表示。redo 记录的是"页号 5、偏移 0x40 起 8 字节改成 X"这样的增量，而不是整页 16 KB。一条改单列 INT 的记录通常只有几十字节，比页小两三个数量级。

1
2
3
4
5
6

 不用 WAL（假设）：                       使用 WAL（InnoDB 实际做法）：
 事务 T 提交时必须把 5 个脏页写回磁盘     提交时只需把 redo 追加到 log file
   5 次随机写，位置毫无规律                 1 次顺序写，几十~几百字节
   page#17 page#3 page#88 page#41 page#9    log file: [rec][rec][rec]...
   ~100 μs 各一次（SSD 口径）               ~一次 fsync 的量级
   最坏：部分页写成功 → 页内结构损坏         脏页可以慢慢刷；崩溃后重放 redo

21.1.2 innodb_flush_log_at_trx_commit 的三种取值与丢失窗口

这个参数的名字常常误导人：它管的是提交时 redo log 如何落盘，而不是"多久刷一次脏页"。

21.1.3 为什么不让日志直接替代数据页

常见追问：“既然 redo 记了所有修改，为什么不只留 redo、不要数据页？“答案是恢复时间必须有上界：checkpoint 不断推进，把"该 LSN 之前的脏页都已刷盘"记下来，崩溃后只需从最近一次 checkpoint 重放。若不刷脏页，checkpoint 永远停在开头，恢复时长随运行时间线性增长。刷脏页不是为了省日志，而是为了让恢复时间有界。

21.2 redo log：物理逻辑日志与环形结构

21.2.1 物理逻辑 的含义

redo log 的记录分两种粒度：物理层记录"哪个表空间的第几号页、页内哪个偏移、改成什么字节”，靠 (space_id, page_no, offset, len, data) 定位；逻辑层面对"插入一行导致页分裂"这类操作，不记录分裂后每个字节的最终形态，而是记录"在某索引上插入主键为 K 的记录”，由重放线程重新执行、得到确定结果。

所以准确说法是物理逻辑日志（physiological logging）：页内改动的重放是幂等的、不依赖 B+ 树当前结构，同时又能把页分裂这种逻辑操作表达得足够短。

21.2.2 LSN：三个位置记录的同一个数

LSN（Log Sequence Number）是单调递增的字节偏移量，8 字节整数，表示"日志已经写到哪儿了”。它出现在三处，混淆这三处是高频扣分点：

判断一个数据页是否需要重放，靠的是页头 LSN 与 checkpoint LSN 比较：页的 FIL_PAGE_LSN 小于 checkpoint LSN，说明它的修改早已刷盘，无需重放；反之才需要。这样恢复时不必扫描所有页。

21.2.3 环形结构与"日志写满"的后果

redo log 在 8.0.30 之前是固定大小的循环文件组（innodb_log_file_size × innodb_log_files_in_group），8.0.30 起改为 innodb_redo_log_capacity（默认 100 MB）统一控制，但环形语义不变：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

     innodb_redo_log_capacity（循环使用的总空间）
  ┌──────────────────────────────────────────────────────┐
  │  ┌──────────┐  ← 可被覆盖 →   ┌──────────┐           │
  │  │ 已刷盘区域 │                │ 待刷盘区域 │           │
  │  └──────────┘                └──────────┘           │
  │       ▲                            ▲                 │
  │  checkpoint LSN                write pos             │
  │ （脏页已刷到的位置）        （日志已写到哪）            │
  └──────────────────────────────────────────────────────┘
   checkpoint 与 write pos 之间 = 尚未刷盘的脏页所依赖的日志
   write pos 追上 checkpoint  ⟹ 环形缓冲区写满

写满时发生什么：新事务要写 redo，但 write pos 已追到 checkpoint，环形空间没有空闲。此时 InnoDB 必须强制推进 checkpoint——把一批脏页刷盘（innodb_page_cleaners 与刷脏线程参与），刷完才能腾出日志空间。这期间新写入被阻塞，表现为"刷脏抖动"、写入 RT 尖刺；若刷脏速度跟不上日志产生速度，就是持续停顿。由此得两条工程结论：容量不宜过小（否则刷脏被迫提前，失去"把随机写攒成顺序写"的合并收益），经验口径是能容纳 1~2 小时的写入量；刷脏成为瓶颈时症状是写入周期性卡顿而 CPU 不高，观测点是 SHOW ENGINE INNODB STATUS 里 Log sequence number 与 Last checkpoint at 的差距。

21.2.4 组提交：三个阶段各排一次队

一次提交只要 innodb_flush_log_at_trx_commit = 1，就必须 fsync。而 fsync 是整条链路上最贵的单点操作（机械盘约 5_{10 ms，SSD 约 0.1}1 ms 量级）。如果每个事务各自 fsync，QPS 会被硬压到每秒几百。组提交（group commit）的做法是把并发事务分成三阶段、每阶段排队，由 leader 代大家做一次真正的刷盘/落盘：

1
2
3
4
5
6

  阶段 1 flush        阶段 2 sync              阶段 3 commit
  ────────────        ────────────             ────────────
  T1..T5 各自写        T1..T5 排成一队            T1..T5 按序写
  redo/binlog 缓存     一次 fsync 覆盖全队        引擎层 commit 标记
                       （leader 执行）            （顺序不能乱，否则
                                                  binlog 顺序与提交顺序不符）

三个阶段必须拆开，是因为每个阶段能合并的对象不同：flush 合并"从用户态缓冲区写进文件"，sync 合并 fsync（收益最大），commit 合并"引擎层提交"（本身无 I/O，但不排队就会退化成每个事务各自拿锁，把前面的收益吃掉）。

binlog_group_commit_sync_delay（微秒）与 binlog_group_commit_sync_no_delay_count 是"用延迟换吞吐"的旋钮：sync_delay = 1000 表示 leader 在 sync 阶段故意等最多 1 ms，把这段时间到达的事务攒成更大一批，一次 fsync 覆盖更多事务；no_delay_count 规定"攒够 N 个就不再等"。代价是每个事务至少多等这段时间：它换来的是吞吐与 P99 稳定性，牺牲的是平均延迟——高并发批量场景收益明显，低并发时纯粹自伤。

21.2.5 innodb_flush_method 与 O_DIRECT

innodb_flush_method 决定数据文件与日志文件的打开方式，核心分歧是要不要绕过 OS page cache：默认 fsync 走 buffered I/O，同一页在 buffer pool 与 page cache 各存一份，但保留内核的写合并与预读；O_DIRECT 绕过 page cache 直接写盘，省内存但失去预读与写合并；O_DIRECT_NO_FSYNC 在 O_DIRECT 基础上不再为元数据额外 fsync，只在文件系统（如 xfs）已保证元数据时可用。

关键点：O_DIRECT 不会让 redo 的 fsync 语义消失。它只改变脏页回写路径，提交时的持久化仍由 innodb_flush_log_at_trx_commit 决定。它要求按扇区对齐（512 B 或 4 KB），未对齐的 I/O 会被内核退回 buffered 路径。

21.3 undo log：逻辑日志与两个作用

21.3.1 记录的是反向操作

undo log 是逻辑日志：不记录"页 5 的偏移 0x40 原来是 X”，而记录"把插入的行删掉"或"把 age 从 24 改回 23"这样的反向操作。回滚时由引擎重新执行这些反向操作，而不是把字节倒回去。原因是同一个逻辑修改可能落在不同的物理位置（页分裂、记录迁移），只有逻辑层才能保证回滚到正确的语义状态。

undo 有且只有两个作用：

1. 事务回滚：显式 ROLLBACK，以及崩溃恢复时对未提交事务的回滚；
2. MVCC 快照读：为一致性读提供历史版本，版本链的构建与可见性判断细节见第 22 章 22.3 节。

21.3.2 insert undo 与 update undo：提交后能否立即删除

undo 页的回收规则取决于提交后还有没有人需要这个版本。

update undo 的回收由 purge 线程完成。它判断"这个版本还有没有人需要"的依据是最老的活跃 ReadView：如果一个 undo 记录对应的 trx_id 已经不早于任何活跃事务可见需要的时间点，它就可以被清理。innodb_purge_threads（默认 4）控制 purge 线程数，undo 表空间由 innodb_undo_tablespaces 控制（8.0 默认 2 个，可增长）。

长事务的危害链在这里闭环：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 长事务长期不提交
      │  该事务的 ReadView 一直活跃
      ▼
 purge 无法越过"最老活跃 ReadView"推进 → 历史版本一个都不能删
      │
      ▼
 undo 表空间持续膨胀 + 版本链越来越长 → 每次快照读都要沿链回溯比较 trx_id
      │
      ▼
 查询变慢、undo 页 I/O 变多、purge 追不上 → 回滚段耗尽风险

21.3.3 回滚与崩溃恢复中的 undo

崩溃恢复的重放阶段会把所有已落盘的 redo 都重新应用，包括尚未提交、甚至刚写入 prepare 的事务。所以重放结束后，库里必然存在一批"物理上已改、逻辑上不该存在"的事务，必须靠 undo 把它们回滚掉：redo 让数据前进到崩溃前一刻，undo 再让未提交的事务后退。这也解释了为什么 undo 必须在数据修改之前写入——若 undo 后写而崩溃在中间，恢复时既不知道原值是什么、也无法回滚。

21.4 binlog：Server 层的逻辑日志

21.4.1 与存储引擎无关

binlog 由 Server 层写入，记录"逻辑上发生了什么"，与用哪个引擎无关。它有三个用途：主从复制（从库重放，机制见第 26 章 26.2 节）、归档、按时间点恢复（point-in-time recovery, PITR）——先用全量备份恢复，再重放备份点之后的 binlog。三种格式的对比是必考项（binlog_format 是会话级变量，可运行时切换，但链路上每一段——主库、从库 SQL 线程、级联从库——都必须能正确处理收到的格式，所以生产上是"统一用 ROW"的运维纪律）：

为什么互联网公司普遍选择 ROW：不是因为它"更先进"，而是因为它在语义上排除了非确定性——从库不再"重新执行逻辑"，而是"照着行像改"，因此主从数据在行级别强一致。代价是日志量大，DELETE/UPDATE 大范围操作时可能比 STATEMENT 大几个数量级，需要用 binlog_row_image = MINIMAL 压缩：只记录主键（前像）与实际改变的列（后像）。

21.4.2 写入时机与 sync_binlog

binlog 的写入分两步，都发生在事务提交阶段：事务执行期间，SQL 语句（或行像）先写进每个会话私有的 binlog cache（超出 binlog_cache_size 会溢出到临时文件）；提交时把 cache 内容 write 进 binlog 文件，再按 sync_binlog 决定是否 fsync。

双一配置指 sync_binlog = 1 且 innodb_flush_log_at_trx_commit = 1，即"每个事务至少两次 fsync（binlog 一次、redo 一次）"。这两次 fsync 不丢，靠的正是组提交把并发事务合并——sync_binlog = 1 并不意味着"一次提交一次 fsync"，而是"每个提交批次至少一次 fsync"。

binlog 的滚动由 max_binlog_size（默认 1 GB）触发，但单个事务超过该值时不会在事务中间切开（切开会让从库读到半个事务），所以实际文件可能超出。过期删除由 binlog_expire_logs_seconds（8.0.11 起，默认 2592000 秒即 30 天）控制，早期版本是 expire_logs_days。手工清理用 PURGE BINARY LOGS TO 'mysql-bin.000123'，但从库还没消费到该位置就不能删，否则复制直接中断。

21.5 两阶段提交：崩溃点分析

21.5.1 时序图

两阶段提交（two-phase commit, 2PC）在这里不是分布式事务协议，而是 InnoDB 与 Server 层 binlog 之间的内部一致性协议：redo 与 binlog 分属两个写入者，没法放进同一个原子操作，一旦中间崩溃两者就会各说各话。注意要点：redo 先落盘、binlog 后落盘，顺序不能反；这也是为什么参数动词是 flush_log_at_trx_commit——它管的是 redo，而不是 binlog。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 事务执行              【阶段一 prepare】              【阶段二 commit】
 ─────────              ──────────────────             ──────────────────
 改 buffer pool  ──▶  redo 写盘（带 prepare 标记）──▶
 写 undo         ──▶  事务进入 prepare 状态      ──▶  binlog 写盘（write + fsync）
                                                         │
                                                         ▼
                                                     redo 写 commit 标记
                                                         │
                                                         ▼
                                                     引擎层提交、锁释放、事务可见

21.5.2 三种崩溃时机各自恢复成什么

崩溃点分析要盯住一个不变式：binlog 一旦完整落盘，就一定会被从库消费。所以恢复的目标是让主库与从库对齐，而不是让主库"尽量保留"。

时机 ①：写完 redo prepare 之后、写 binlog 之前崩溃

1
2
3

 redo 有 prepare、无 commit；binlog 中没有该事务
 恢复判断：prepare + binlog 不存在 → 回滚
 主库被回滚、数据不存在；从库没有收到它 ⟹ 一致（都"没做"）

时机 ②：写完 binlog 之后、写 redo commit 之前崩溃

1
2
3

 redo 有 prepare、无 commit；binlog 中该事务完整
 恢复判断：prepare + binlog 完整 → 提交
 主库被提交、数据存在；从库重放后数据存在 ⟹ 一致（都"做了"）

时机 ③：binlog 写了一半（或校验失败）崩溃

1
2
3

 redo prepare；binlog 末尾存在截断或校验不通过的 event
 恢复判断：binlog 不算"完整" → 回滚，尾部截断到最后一个完整 event
 从库只重放了已收到的完整 event ⟹ 一致（都"没做"）

21.5.3 为什么决断依据必须是"binlog 是否完整"

因为binlog 是"对外已经生效"的凭据——从库只认 binlog。恢复时主库只能"跟着 binlog 走"：binlog 说做了，主库就必须做（否则主库比从库少数据，后续复制会报错或静默分叉）；binlog 说没做，主库就必须回滚。用 redo 的状态决断是不行的：时机 ② 里 redo 只有 prepare，若按"没 commit 就回滚"处理，主库回滚而 binlog 已发给从库，从库执行了——主从立刻不一致。

binlog_checksum（5.6.2 起支持，5.6.6+ 默认 CRC32）是"完整性"落在字节上的实现：每个 event 尾部带 4 字节校验和，写入中断会留下校验失败的尾部事件，恢复据此认定 binlog 不完整、选择回滚并截断。注意它只保证单个 event 的字节完整性，不保证事务边界完整——后者靠 event 组末尾的 XID 事件是否存在。

21.5.4 不做 2PC 会怎样

第一种更危险：它破坏了"从库可以被主库重建"这条底线；第二种虽也错，但至少能用主库重做从库。2PC 的代价是每个事务多一次 fsync 与一次状态写，收益是"binlog 与数据文件永远可以互相推导"。

21.6 redo log 与 binlog 的分工

21.7 崩溃恢复的完整流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 ① 找最近一次 checkpoint LSN（SHOW ENGINE INNODB STATUS 或 redo 文件头）
 ② 从 checkpoint 起前向重放 redo（redo apply / 前滚）
      ├─ 比对页头 FIL_PAGE_LSN，跳过"修改已刷盘"的页
      ├─ 重放范围包含未提交事务、含 prepare 事务的修改
      └─ 结束后：数据页 = 崩溃前最后一刻的物理状态
 ③ 扫描事务状态，挑出仍处于 prepare 的事务
 ④ 用 binlog 决断：完整 → 补写 redo commit 标记并提交；不完整/不存在 → 回滚
 ⑤ 回滚其余未提交事务（靠 undo 反向操作）
 ⑥ binlog 尾部若校验失败 → 截断到最后一个完整 event 组
 ⑦ 开始接受连接；undo 的后续清理交给 purge 线程

第 ③④ 步的实现细节值得记住：InnoDB 在 prepare 阶段会把事务的 XID 一并写进 redo，恢复时用这个 XID 去 binlog 里查找对应的事件组。找到且完整 → 提交；找不到或尾部不完整 → 回滚。这就是"用 binlog 决断"在代码层面的落地方式。

21.7.1 innodb_force_recovery 的分级

当 redo 或数据页本身损坏（重放到坏页导致启动失败）时，需要人工降级启动：

本章小结

自测题

Q1（推导）一台机器上的 MySQL 配置为 innodb_flush_log_at_trx_commit = 2、sync_binlog = 1。请分别说明：mysqld 进程被 kill -9、操作系统 panic、机房整体掉电三种情况下，一个刚刚 COMMIT 返回成功的事务会不会丢，为什么。

Q2（判断）有同事主张："innodb_redo_log_capacity 设大一点没有坏处，反正日志是循环使用的，占的磁盘也不会变多。“请判断并说明调大与调小的各自代价，以及"日志写满"时的具体行为。

Q3（分析）一次事务提交过程中，实例在写完 redo 的 prepare 标记、写完完整的 binlog 事务组、还没来得及写 redo commit 标记时掉电。请说明重启后该事务的最终状态、从库的状态，并解释为什么不能用"redo 里没有 commit 标记"作为回滚依据。

Q4（设计）线上一个报表任务在事务里跑了 40 分钟才提交，期间磁盘上 undo 目录持续增长，并且其他会话的快照读逐渐变慢。请解释这条因果链，并给出至少三条处置措施（含具体参数或 SQL）。

1
2
3
4
5

-- 找出运行时间最长且未提交的事务：元凶是"最老"的那个，不是"改行最多"的那个
SELECT trx_id, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS secs, trx_rows_modified, trx_state
FROM information_schema.INNODB_TRX ORDER BY trx_started ASC LIMIT 10;
-- History list length 长期只增不减，就说明 purge 被最老的活跃 ReadView 钉住了
SHOW ENGINE INNODB STATUS\G

Q5（设计）你的团队要在 MySQL 8.0 上扛住每秒上万次的单行 INSERT，且不能丢已提交数据。请给出从参数到应用的完整优化清单，说明每一项为什么有效，以及它的代价。

面试高频问题与陷阱

延伸阅读

• MySQL 官方手册 “InnoDB On-Disk Structures → Redo Log” 与 “Undo Logs”：innodb_redo_log_capacity 与 innodb_undo_tablespaces 的行为口径、8.0.30 前后的参数差异以它为准。
• MySQL 官方手册 “Server Administration → The Binary Log”：binlog_format、binlog_row_image、sync_binlog、binlog_expire_logs_seconds 的定义与默认值来源。
• MySQL 官方手册 “InnoDB Startup Options and System Variables” 中 innodb_flush_log_at_trx_commit、innodb_flush_method、innodb_force_recovery 三节：本章 21.1.2、21.2.5、21.7.1 节的参数语义依据。
• MySQL 官方手册 “MySQL Server Logs → Binary Log → Binary Logging Formats”：三种格式差异与"不确定函数"清单的规范出处。
• MySQL 官方博客 “MySQL 8.0.30: New redo log capacity” 与 “Binary Log Group Commit”：环形容量与组提交三阶段队列的第一手说明。
• MySQL 官方手册 “InnoDB Recovery” 与 innodb_force_recovery 的分级表：各级允许的操作与限制。
• man 2 fsync、man 2 open：O_DIRECT 的对齐要求与 fsync 的持久化语义，21.2.5 节讨论的基础。
• 第 20 章 20.4、20.5 节（页结构与一条 UPDATE 的生命周期）、第 22 章 22.3 节（版本链与可见性判断）、第 26 章 26.2 节（binlog 如何被从库消费）：本章的前置与后继。