WAL预写日志怎样恢复数据

WAL（Write-Ahead Logging，预写日志）是数据库中保证数据持久性和崩溃恢复的核心机制。其基本思想是：任何数据修改先写日志，再改内存/磁盘页，这样即使系统崩溃，也能通过日志把未完成或已提交但未落盘的数据恢复出来。

下面按「原理 → 恢复流程 → 关键细节 → 示例」系统说明。

一、WAL 的核心原理（为什么能恢复）

1. 先写日志，后写数据

   • 事务修改数据时：
     1. 生成 redo 日志记录（包含：事务ID、页ID、偏移、旧值/新值）
     2. 写入 WAL（顺序写，快）
     3. 再修改内存中的页（buffer pool）
   • 只有日志落盘后，事务才能提交

2. 崩溃时内存丢失，但日志还在

   • 已提交事务：日志已写盘 → 可重放
   • 未提交事务：日志可能部分写盘 → 需回滚

二、WAL 数据恢复的标准流程

数据库重启后，恢复通常分三个阶段：

1️⃣ Analysis（分析阶段）

• 读取 WAL
• 确定：
  • 哪些事务已提交
  • 哪些事务未提交
  • 哪些数据页需要恢复
• 找到 最后一个检查点（checkpoint）

2️⃣ Redo（重做阶段）

• 从 checkpoint 开始
• 对所有已提交 + 未提交事务的日志记录：
  • 按日志顺序重放修改
• 目的：
  • 把内存中“应该存在但丢失”的数据恢复出来
• 即使事务未提交，也要 redo（后面再 undo）

✅ Redo 保证：所有已提交数据一定存在

3️⃣ Undo（回滚阶段）

• 对未提交事务
• 按日志反向执行：
  • 用旧值覆盖新值
• 目的：
  • 保证事务原子性

✅ Undo 保证：未完成事务像没发生过

三、WAL 恢复的关键机制

✅ Checkpoint（检查点）

• 定期把内存脏页刷盘
• 记录“到此为止，前面日志已安全”
• 恢复时只需从 checkpoint 之后开始

✅ LSN（Log Sequence Number）

• 每条日志唯一编号
• 数据页也记录最近修改的 LSN
• 用于判断：
  • 该日志是否已应用
  • 避免重复 redo

✅ 原子写 & 幂等

• Redo 是幂等的（重复执行结果一致）
• 崩溃可能在任意位置，恢复必须安全

四、一个简单例子

事务 T1：

UPDATE account SET balance=100 WHERE id=1;
COMMIT;

执行过程：

1. 写 WAL：

   T1: update id=1, old=0, new=100
   T1: commit
   

2. 改内存页
3. 还没刷盘就崩溃

恢复时：

• Analysis：T1 已提交
• Redo：把 id=1 的 balance 设为 100
• 数据恢复成功 ✅

五、不同数据库的 WAL 实现

六、总结一句话

WAL 恢复数据的本质：
用“先写日志”的顺序，在崩溃后通过 Redo 重做已提交操作 + Undo 撤销未提交操作，把数据库恢复到一致状态。

如果你愿意，我可以：

• 画一张 WAL 恢复流程图
• 讲 PostgreSQL / MySQL 的具体恢复过程
• 或结合 崩溃场景逐步推演

你想深入哪一块？