S11-J05 · 日志与恢复：redo / undo / binlog

适用读者：想知道"误删了还能不能救"的人。
前置：S11-B06（事务）。
覆盖旧文：852(97) 2396(440) 2694(126) = 663 点。
覆盖扩展：E-S11-019（三种日志的归属与作用）。
上一篇：S11-J04 · 慢查询排查与调优
下一篇：S11-A01 · 引擎、主键与锁。

1. 一句话结论

三种日志分工明确：redo log（引擎层，崩溃恢复，保证已提交不丢）、undo log（引擎层，回滚 + MVCC）、binlog（Server 层，归档/复制/审计）。

日志	属于	作用	内容
redo log	InnoDB 引擎	崩溃恢复（已提交的事务不丢）	物理页修改
undo log	InnoDB 引擎	回滚 + MVCC 旧版本	逻辑反向操作
binlog	Server 层	归档、主从复制、按时间点恢复	逻辑 SQL/行变更

"为什么 binlog 能做时间点恢复（PITR），redo 不能"：binlog 是逻辑记录（可重放），redo 是物理页（只能恢复到一致状态，且循环写会覆盖）。

2. 一条 `update` 的完整路径

① 从磁盘读页到 buffer pool
② 改内存页
③ 写 undo log（旧值，供回滚）
④ 写 redo log（改动，先进入 redo buffer → 刷盘）
⑤ 写 binlog（提交阶段）
⑥ 提交（两阶段：redo prepare → binlog → redo commit）
⑦ 后台刷脏页

两阶段提交（2PC） 就是为了让 redo 与 binlog 一致——否则崩溃后可能出现"主库有、从库没有"。

3. 误删数据怎么救（A-2694）

情况	手段	前提
`delete`/`update` 误操作	binlog 反向解析（binlog2sql 类工具）	binlog 开启且 `ROW` 格式
`drop`/`truncate`	只能全量备份 + binlog 重放	有定期全备
整库丢失	备份恢复	备份可用

判据："我的 binlog 格式是 ROW 吗？有没有定期全备？" 两条缺一，恢复就很麻烦。

"delete 比 truncate 好救"——这也是 B04 的一条实践建议：能 delete 就不要 truncate/drop（牺牲速度换可恢复性）。

4. 主从复制与延迟

概念	说明
复制链路	主库 binlog → 从库 relay log → 重放
主从延迟	从库重放慢于主库写入
常见原因	大事务、无主键表（ROW 格式下全表扫）、从库单线程重放

延迟的应对：并行复制、拆分大事务、关键读走主库（S08-A02）。

5. 五个误区

误区	真相
"有 redo 就不用 binlog"	redo 不能做 PITR/复制
"binlog 一定能救 truncate"	需要全备 + 重放
"`delete` 和 `truncate` 恢复难度一样"	truncate/drop 难得多
"主从延迟只影响读"	也影响备份一致性与切流
"两阶段提交是可选优化"	是 redo/binlog 一致性的必需

6. 自检

三种日志各属于哪一层、各做什么？
为什么 binlog 能做 PITR 而 redo 不能？
一条 update 经过哪几步？两阶段提交解决什么？
truncate 与 delete 的恢复难度差异？
主从延迟的三个常见原因？

7. 下一篇

S11-A01 · 引擎、主键与锁

日志讲完，进架构师层：InnoDB/MyISAM 的取舍、自增主键为什么不连续，以及死锁（含实测复现）。

本篇属于系列《S11 · 数据库与 SQL》。旧文来源：A-852/2396/2694；扩展点 E-S11-019。