CMU15-445 数据库系统播客：日志与恢复机制解析

2025-10-10

在数据库的世界里，我们理所当然地认为，当我们按下“提交”按钮时，数据就安全了。即使下一秒机房断电、系统崩溃，我们相信重启后数据依然完好无损。这份“信任”的背后，是一套精密而强大的机制在默默守护——这就是数据库的日志与恢复系统。

本文将基于 CMU 顶尖的数据库课程 15-445/645 的核心内容，带你深入探索数据库如何确保其 ACID 特性中的原子性 (Atomicity) 和持久性 (Durability) 。我们将从最基本的问题开始：为什么需要日志？然后逐步揭开缓冲池管理、影子分页 (Shadow Paging) 和现代数据库的基石——预写日志 (Write-Ahead Logging, WAL) 的神秘面纱。

核心矛盾：性能与安全的博弈

现代数据库系统为了追求极致的性能，不会让每一次数据读写都直接操作缓慢的磁盘。相反，它们在内存中开辟了一块高速缓存区，称为缓冲池 (Buffer Pool) 。所有的数据页 (Page) 在被修改前，都必须先从磁盘读入缓冲池。事务的所有操作都在内存中飞速进行。

然而，这也带来了显而易见的问题：内存是易失的。如果系统在事务修改了缓冲池中的数据页（我们称之为“脏页”，Dirty Page）但尚未将其写回磁盘时崩溃，那么所有内存中的修改都会丢失。

为了解决这个矛盾，恢复算法应运而生。它包含两个阶段：

正常运行时：持续记录足够的信息，为可能发生的崩溃做准备。崩溃恢复时：利用记录的信息，将数据库恢复到一个一致的、正确的状态。

恢复的两大基石：Undo 与 Redo

所有恢复算法都建立在两个基本操作之上：Undo 和 Redo。

Undo (撤销) ：确保事务的原子性。如果一个事务在完成（提交）之前中止或系统崩溃，Undo 负责将其所有已做的修改“抹去”，就像这个事务从未发生过一样。为了实现这一点，日志需要记录每个修改的 “前镜” (Before Value) 。Redo (重做) ：确保事务的持久性。如果一个事务已经成功提交，但其修改的某些脏页还没来得及写回磁盘就发生了崩溃，Redo 负责在系统重启后，根据日志重新执行这些修改，确保其效果不会丢失。为了实现这一点，日志需要记录每个修改的 “后镜” (After Value) 。

关键决策：缓冲池管理策略

数据库系统如何处理缓冲池中的“脏页”，直接决定了其需要的恢复操作和整体性能。这里有两个关键的策略维度，它们的组合构成了不同数据库的设计哲学。

策略一：STEAL vs. NO-STEAL (是否允许“窃取”)

这个策略决定了未提交事务修改的脏页，是否允许被写回磁盘。

STEAL (允许窃取) ：系统允许将一个尚未提交的事务所产生的脏页写回磁盘。这通常是由于缓冲池空间不足，需要腾出空间给其他数据页。

优点：内存管理更灵活，可以支持远超内存大小的大型事务。缺点：恢复时变得复杂。如果该事务最终中止或在写入磁盘后崩溃，我们就必须执行 Undo 操作，将磁盘上已经被“污染”的数据恢复原状。

NO-STEAL (禁止窃取) ：系统严格禁止将未提交事务所产生的脏页写回磁盘。这些脏页必须保留在内存中，直到其所属事务提交。

优点：恢复简单。由于未提交的修改绝不会出现在磁盘上，我们永远不需要在磁盘上执行 Undo。缺点：严重限制内存使用。如果一个事务修改的数据量超过了缓冲池的容量，该事务就无法执行。策略二：FORCE vs. NO-FORCE (是否强制落盘)

这个策略决定了事务提交时，是否必须将其产生的所有脏页立即写回磁盘。

FORCE (强制写入) ：当一个事务提交时，系统强制要求将该事务所修改的所有脏页立即同步到磁盘。

优点：恢复极快。因为所有已提交的修改都已确保在磁盘上，所以恢复时完全不需要 Redo 操作。缺点：运行时性能极差。每次提交都需要进行大量（可能是随机的）磁盘 I/O，这会成为系统的巨大瓶颈。

NO-FORCE (不强制写入) ：事务提交时，不要求其脏页必须立即写回磁盘。系统只需要确保相关的日志记录已落盘即可。脏页可以在未来的某个时刻由后台进程批量写回。

优点：运行时性能非常高。事务提交变得极为迅速，因为它只涉及一次或几次日志写入，而非大量的数据页写入。缺点：恢复时需要 Redo。如果提交后、脏页写回前发生崩溃，系统必须通过 Redo 来恢复这些已提交的修改。策略组合与权衡

策略组合

需要 Undo?

需要 Redo?

运行时性能

恢复复杂度

NO-STEAL

+ FORCE

否

极差

最简单

NO-STEAL

+ NO-FORCE

否

是

较好

简单

STEAL

+ FORCE

是

否

差

复杂

STEAL + NO-FORCE

是

最优

最复杂

可以看到，NO-STEAL + FORCE 方案虽然恢复最简单，但其性能和内存限制使其在现代高性能场景下几乎不可行。与之相对，STEAL + NO-FORCE 提供了最佳的运行时性能和灵活性，尽管代价是恢复过程最为复杂（需要同时处理 Undo 和 Redo）。

现代主流数据库几乎无一例外地选择了 STEAL + NO-FORCE 策略。它们的设计哲学是：系统崩溃是小概率事件，我们应当优先优化绝大多数时间都在进行的正常操作，将复杂性留给恢复阶段。

早期尝试：影子分页 (Shadow Paging)

影子分页是 NO-STEAL + FORCE 策略的一种经典实现。它虽然现在已不常用，但其思想非常巧妙。

工作原理：

数据库的数据页通过一个树状的页表结构进行组织，有一个根指针指向这个结构的顶端。当一个事务开始修改数据时，它不会直接在原始数据页上修改，而是创建一个该页的副本（影子页）。所有修改都在副本上进行。为了定位到这些副本，系统也会相应地创建页表的副本。这个修改过程会自底向上一直传播到根节点。此时，我们同时拥有了两个版本的数据：一个是由旧根指针指向的、未被修改的主副本 (Master Copy) ，另一个是由新根指针指向的、包含了修改的影子副本 (Shadow Copy) 。事务提交：系统原子性地将磁盘上的根指针从旧的页表树切换到新的页表树。一旦切换成功，所有修改瞬间生效。

Undo/Redo 如何工作？

Undo ：极其简单。如果事务中止，只需直接丢弃所有的影子页和对应的页表副本，主副本毫发无损。Redo ：完全不需要。因为 FORCE 策略保证了在提交（即指针切换）时，所有修改过的数据页和页表都已被完整写入磁盘。

为什么被淘汰？

高昂的提交开销：每次提交都需要将所有修改过的脏页和页表写入磁盘，涉及大量随机 I/O。数据碎片化：旧版本的数据页散落在磁盘各处，成为垃圾，需要额外的垃圾回收机制。并发性能差：这种模型很难支持多个写入事务高效地并发执行。

现代标准：预写日志 (Write-Ahead Logging, WAL)

WAL 是实现 STEAL + NO-FORCE 策略的黄金标准，被当今几乎所有高性能数据库（如 PostgreSQL, MySQL/InnoDB, Oracle 等）所采用。

WAL 的黄金法则

在将任何数据页的修改写回磁盘之前，必须确保与该修改相关的日志记录（包括 Undo 和 Redo 信息）已经先一步写入到稳定的存储（磁盘）上。

这个法则是 WAL 的灵魂。它意味着：

事务提交时，我们只需等待它的提交日志 (<COMMIT>) 记录被写入磁盘，就可以向客户端确认提交成功。我们不需要等待数据页本身落盘。即使系统在脏页写回前崩溃，我们也能安然无恙。因为重启后，我们可以读取日志，利用 Redo 信息重放已提交事务的修改，利用 Undo 信息回滚未提交事务的修改。WAL 的巨大优势：化随机 I/O 为顺序 I/O

WAL 最核心的性能优势在于，它将对数据文件的大量随机写操作，巧妙地转化为了对日志文件的一次顺序写操作。

数据页在磁盘上是随机分布的，更新它们需要磁头在盘片上反复寻道，非常耗时。日志文件则是仅追加 (Append-only) 的。写入日志永远是在文件末尾进行，这是一个高速的顺序操作，比随机写快上几个数量级。性能优化：组提交 (Group Commit)

如果每个事务提交都立即触发一次磁盘同步 (fsync) 来刷写日志，当并发量很高时，磁盘 I/O 依然会成为瓶颈。为此，数据库引入了组提交机制。

系统会将多个并发事务的日志记录先在内存的日志缓冲区中攒一会儿，然后将这个“批次”的日志记录通过一次 fsync 操作，批量写入磁盘。这大大摊薄了单次磁盘同步的开销，显著提升了数据库的事务吞吐量 (TPS)。

日志的内部：记录的粒度

日志记录具体写了什么内容，也存在不同的实现方式：

物理日志 (Physical Logging) ：记录字节级别的变化，例如：“在页面 P 的偏移量 O 处，将字节序列 A 改为 B”。这种日志非常简单直接，但体积可能很大。逻辑日志 (Logical Logging) ：记录高层次的操作，例如：UPDATE students SET gpa = 4.0 WHERE id = 1。这种日志非常紧凑，但恢复时需要重新执行逻辑，可能很慢，且在并发环境下恢复状态可能与原始执行不一致。生理日志 (Physiological Logging) ：这是物理和逻辑日志的混合体，也是最被广泛采用的方式。它记录对单个数据页的修改，但描述的是逻辑上的变化，而非具体的字节位。例如：“在页面 P 中，将记录 R 的某个字段从值 V1 更新为 V2”。它兼具了恢复效率和日志紧凑性的优点。