事务处理与恢复

一句话

这一章把存储引擎从「一个会存会找的数据结构」升级成一个真正的数据库：ACID 不是某个模块提供的，而是页缓存、预写日志、并发控制三件套合力挤出来的结果。而它们共同的底牌只有一条——改数据之前先把要做的事写进日志。由此得出全章最该记住的一句反直觉判断：磁盘上的数据文件不是数据库的正本，日志才是；数据文件只是日志的一份可以丢弃、可以重算的物化结果。

Glossary · 术语表

坐标

本章是 Part I「存储引擎」的第 5 章，也是这一部分的收口之作。前四章——引论与概览、B-Tree 基础、文件格式、实现 B-Tree——描述的都是一个静态、单线程、永不断电的世界里数据该怎么摆。这一章把那棵树扔进真实世界：会有几百个并发连接同时读写它，随时可能断电。往后，Ch6（B-Tree 变体）里的写时复制（copy-on-write）就是「换一种方式实现原子性」的分支，Ch7（LSM-Tree）则把本章的「日志」直接抬成主存储结构；而 Part II 的 Ch13 分布式事务，本地那一半正是这里讲的东西。

这章要解决什么

把前四章的成果摆到一起，会看见一个尴尬的缺口：一次逻辑上「原子」的改动，落到存储引擎里往往要动好几个页。往 B-Tree 插一条记录可能触发叶子分裂、父节点加指针、甚至根节点上移——三四页各自的修改，中间任何一刻断电，磁盘上留下的就是一棵结构损坏的树：指针指向一个还没写完的页，整个索引作废。

而这些页都不是直接改在磁盘上的，是改在内存的页缓存里——也就是说，任何时刻磁盘上的数据文件都处在「过期且不自洽」的中间状态。再叠上几百个事务同时读写，问题就拧成三股：内存与磁盘之间的搬运怎么既快又可控（页缓存与驱逐、检查点）、断电后怎么从一堆半成品里还原出自洽的数据库（日志与恢复）、并发事务之间怎么不互相看到半成品（并发控制）。不解决它们，数据库能给的最强承诺只有「祝你好运」。

核心内容，讲透

一、四道关卡：ACID 是被谁分别扛下来的

面试里问「ACID 怎么实现的」，标准答案不是一句话，而是一张分工表。一个事务从进入引擎到提交，依次经过四个组件：事务管理器协调整笔事务、决定提交还是中止；锁管理器守住被访问的逻辑对象，别的事务想碰就排队；页缓存把页从磁盘调进内存，所有修改都发生在这里；日志管理器把「我准备怎么改」先写成日志。

二、页缓存：数据库为什么坚持自己管内存

操作系统本来就有文件缓存，数据库为什么还要自己做一层？因为它需要三件操作系统给不了的东西：知道哪些页正被人用（不能踢）、哪些页被改过（踢之前必须先落盘）、以及决定谁先落盘的权力。这三件都直接关系正确性，交不出去。

关键动作有四个。钉住（pinning）：页正被使用时加引用计数，不为零就不许驱逐——B-Tree 往下走时，路径上的页都是钉住的。标脏：内存里改过就打标记。驱逐（eviction）：缓存满了挑一个没被钉住的页踢掉；若它是脏的得先写回，而写回之前还必须确认覆盖它的日志已落盘。检查点：与其等缓存满了被动零星刷盘，不如定期主动成批刷，顺便在日志里打个标记，把恢复起点往前推。

驱逐策略比课本上的 LRU 复杂得多，原因很实际：朴素 LRU 会被一次全表扫描彻底冲垮。一条 SELECT * FROM 大表 顺序读过几百万页、每页只用一次，却把攒了几小时的热点页全挤出去——扫描结束，命中率归零，接下来几分钟所有查询都在打磁盘。所以 MySQL InnoDB 把 LRU 链表切成「新 / 旧」两段：新读进来的页先插在中点（旧段头部）而不是最前面，再次被访问才升级进新段——一次性扫描的页只在旧段里打个转就被淘汰，碰不到热点。旧段默认占 3/8（innodb_old_blocks_pct 默认 37）。

三、预写日志：用一次顺序写，换掉几十次随机写

WAL 的规则只有一句话，却撑起整章：任何对数据页的修改，其日志记录必须先于该数据页落盘。反过来读更有味道——只要日志在，数据页何时落盘就完全自由了，因为随时能照日志重算。数据文件由此降格成「日志的一份物化快照」。

这笔买卖为什么划算，要给量级。一笔事务改了 5 条散落在不同页上的记录：老实刷盘是 5 次随机写；走 WAL 则是把 5 条日志拼进一段连续字节，一次顺序写 + 一次 fsync。机械盘上随机写要付寻道时间（约 5–10 毫秒），顺序写几乎不用；NVMe 上寻道虽已消失，一次 fsync 的固有开销（0.1–1 毫秒量级）仍远大于追加几条记录进日志缓冲。差距还会被组提交（group commit）放大：并发到达的几十笔事务共享同一次 fsync——每秒 5 万笔小事务的负载下，fsync 次数能从 5 万降到几千。

日志里记什么？三种口味。物理日志记「第 700 页第 32 字节从 0x0A 变成 0x14」——重放精确，但一次 B-Tree 分裂会产生大量字节级记录。逻辑日志记「往表 t 插入 (k=42, v=…)」——紧凑，但重放它要求数据库已处在语义完整的状态。ARIES 取折中的物理逻辑日志（physiological logging）：页与页之间是逻辑的、页内部是物理的——记「在第 700 页里插入这条记录」，页内怎么挪字节由页自己负责。

再有两条策略选择，构成全章最经典的四象限。偷（steal）：允许把尚未提交的事务弄脏的页写回磁盘吗？强制（force）：事务提交时必须把它改过的页全写回磁盘吗？

表 1 · steal / force 四象限：为什么工业界几乎一致选了「偷 + 不强制」

读法：左上角最好写，右下角最好用。把复杂度从运行时挪进恢复代码里，是这一章最核心的一次交易——运行时每天跑几十亿次，恢复代码一年跑不了几次。

四、ARIES：先把历史原样重演，再撤销未完成的

ARIES（Mohan 等人 1992 年在 IBM 提出，DB2 的恢复算法）是「偷 + 不强制」这条路上的标准答案。它的恢复分三个阶段，顺序是分析 → 重做 → 撤销。

① 分析：从上一个检查点向前扫日志，重建两张表——脏页表（崩溃时哪些页是脏的、每页最早被哪条日志弄脏）与活跃事务表（崩溃时还没提交的事务，即「输家」）。这一步只是把崩溃瞬间的现场重新画出来。

② 重做：从脏页表里最早那个日志位置开始向前重放。最反直觉的一点在这——ARIES 管它叫重演历史（repeating history）：所有事务的所有改动都重做一遍，包括那些明知属于「输家」、马上就要被撤销的。为什么不聪明点跳过？因为跳过意味着重做逻辑得判断「哪些该做」，而这个判断本身依赖一个尚未还原的状态。先无脑还原到崩溃前一刻、再统一撤销，简单得多也更不易错。避免无谓重放靠的不是聪明，是个笨办法：页头里存着它最后被哪条日志改过（pageLSN），日志编号不比它大就说明这次改动已在盘上，跳过。

③ 撤销：对输家事务沿日志倒着走，逐条抵消。第二个精巧设计在这——补偿日志记录（CLR）：每撤销一步，就再写一条日志记下「我撤销了什么、下一步该撤销哪条」。于是即便数据库在恢复途中又崩一次，重启后照着 CLR 就知道撤销进行到哪了，不会重复撤销。恢复流程因此是幂等的——这点在实践中至关重要，因为「恢复时又崩」恰恰是最常见的连环故障（引发第一次崩溃的坏内存条还在机器里呢）。

五、并发控制：三条路线，以及那个人人搞混的区分

并发控制要挡住一组异常：脏读（读到别人没提交的数据）、不可重复读（同一事务里两次读同一行结果不同）、幻读（两次范围查询看到的行数不同）。理论上的黄金标准是可串行化（serializability）——并发执行的结果等价于把这些事务按某个顺序一个个跑完。隔离级别，本质就是用放宽哪几种异常，换多少并发度。

实现路线有三条。悲观（锁）：先申请锁再动手，冲突就等，靠两阶段锁（先只加、后只放）保证可串行化。乐观（OCC）：先干，提交前再检查这期间有没有人跟我冲突，有就整笔重来。多版本（MVCC）：写不覆盖旧值而是产生新版本，读按自己的时间戳取「当时该看到的那个版本」——读永远不阻塞写、写也不阻塞读，这正是它在 OLTP 场景压倒性流行的原因（PostgreSQL、InnoDB、Oracle 都是 MVCC）。

然后是本章最该单独拎出来的一对概念，也是数据库面试最高频的辨析题——锁（lock）与闩（latch）。中文都译成「锁」，可它们连守护对象都不是一回事。

表 2 · 锁 vs 闩：中文同名，实则两个世界

闩最漂亮的用法是 B-Tree 上的闩蟹行（latch crabbing）。往下查找时，每层都持闩不放，根节点就成了全库瓶颈；一层不持，又可能读到一个正在分裂的中间节点。蟹行的规则是像螃蟹倒手一样，先抓住孩子，确认孩子「安全」后再松开父亲——「安全」指这次写不会让该节点分裂或合并（有足够空位），那它的祖先就绝不会被波及，可以放心松手。全程手里最多攥两层。

顺带一提，Blink-tree 更进一步：给每个节点加一个指向右兄弟的指针和一个「最高键」。这样即使你读到的是一个刚分裂完、还没来得及更新父指针的节点，也能顺着右指针自己找到该去的地方——用一点结构冗余换掉了一部分加闩需求。

关键权衡与选型

表 3 · 三条并发控制路线：什么场景选什么

表 4 · 页缓存驱逐策略：为什么没人用课本上的 LRU

还有一组不进表、但选型时必须掂量的权衡：

• 检查点频率。做得勤：每次刷的脏页少、崩溃后恢复快，但持续占用磁盘带宽、干扰正常负载。做得稀：日常更快，但崩溃后要重放的日志更长——恢复时间目标（RTO）本质上是被检查点间隔定住的。PostgreSQL 的 checkpoint_timeout 默认 5 分钟，正是在「日常开销」和「最坏恢复时间」之间取的一个保守中值。
• 日志刷盘的严格程度。老实 fsync，提交延迟高但真丢不了；放宽成「每秒刷一次」（如 InnoDB 的 innodb_flush_log_at_trx_commit=2），吞吐能提升数倍，代价是崩溃可能丢掉最后一秒的已提交事务——这是拿持久性 D 直接换性能，只有在业务明确能接受时才可以按。
• 隔离级别。往下调一级（比如从可串行化调到读已提交）能显著提高并发，但放进来的异常要由应用自己防。最典型的陷阱是快照隔离下的写偏斜（write skew）：两个事务各自读到一致的快照、各自做出合法的决定，合起来却破坏了约束——比如「至少留一名医生值班」，两个医生同时看到「还有另一个人在」然后都请了假。

为什么重要 / 落到真实系统

这一章是所有单机数据库的公共地基，抽象几乎没有过时：PostgreSQL、InnoDB、SQLite、SQL Server 的恢复路径都是 ARIES 的变体或简化；就连 RocksDB 这类 LSM 引擎，内存表前面也挡着一个功能完全相同的 WAL。往上一层，它还是分布式事务的本地一半——两阶段提交里「参与者承诺我一定能提交」，兑现手段正是本地日志已经落盘。面试里「WAL 为什么快」「redo 和 undo 各解决什么」「lock 和 latch 有什么区别」都是常规题，分水岭就在能不能说清本章这几条因果。

易错点与争议

• 把锁和闩混为一谈（面试最高频的失分点）。守护对象、生命周期、死锁处理全不同；说「B-Tree 遍历时加锁」几乎总是错的——那是加闩。
• 以为「提交返回成功」= 数据页已经在磁盘上。不是。那一刻保证的只有日志已落盘，数据页可能几分钟后才被检查点刷下去。这正是「持久性」的真实含义，也是恢复流程必不可少的原因。
• 以为 ARIES 恢复只做撤销。恰恰相反，它先重做全部历史（包括注定要回滚的事务）再撤销；这个「多此一举」换来的是极大简化、且可重入的恢复流程。
• 以为 MVCC 就是无锁、没冲突。它消除的是读写之间的阻塞；写写冲突依然要靠锁或提交时验证解决。而且快照隔离不等于可串行化——写偏斜就是它挡不住的经典漏网之鱼。
• 以为 fsync 返回成功就万事大吉。fsyncgate 证明这条假设能在最主流的操作系统上悄悄失守 20 年。真正的持久性要求硬件、固件、文件系统、数据库四层都不撒谎。
• 时代局限。本章模型的前提是「磁盘远慢于内存，所以值得用日志把随机写换成顺序写」。这个前提正在两头松动：持久内存与超低延迟 NVMe 缩小了写日志的相对收益，学界因此有大量绕开传统 WAL 的内存数据库恢复方案；云原生数据库（如 Aurora）则把日志下推到存储层，让「检查点」「崩溃恢复」在数据库进程里几乎消失。另外本章对分布式恢复几乎没着墨——那要等 Part II 的 Ch13。

要点