WAL预写日志的工作原理是什么

WAL（Write-Ahead Logging，预写日志）是数据库和存储系统中用来保证数据持久性和崩溃恢复能力的核心机制。

下面从“是什么、为什么、怎么工作、恢复过程”几个角度说明。

一、WAL 的核心思想

在任何数据页（Data Page）被修改并写入磁盘之前，必须先把这次修改记录到日志中，并且日志要先于数据落盘。

一句话总结：

先写日志，再改数据。

二、为什么需要 WAL

如果没有 WAL，直接修改磁盘上的数据页，会出现问题：

• 写数据页到一半系统崩溃 → 数据不完整
• 无法判断哪些事务已提交
• 恢复时只能靠“运气”

WAL 的好处：

1. 崩溃后可恢复（通过日志重放）
2. 提高性能（顺序写日志比随机写数据快）
3. 支持事务 ACID（尤其是 Durability）

三、WAL 的基本组成

通常包含：

• 日志序列号（LSN, Log Sequence Number）
  • 唯一标识一条日志记录
• 事务 ID（TxID）
• 操作类型（INSERT / UPDATE / DELETE）
• 修改前数据（Undo，可选）
• 修改后数据（Redo）
• 提交标记（Commit）

四、WAL 的工作流程（写流程）

以一次 UPDATE 为例：

1. 事务开始

BEGIN TRANSACTION

2. 修改内存中的数据页

• 数据页在 Buffer Pool（内存）中被修改
• 此时磁盘上的数据页还是旧的

3. 写 WAL 日志

在数据页落盘前：

[LSN=101] TxID=7 UPDATE row=5 old=10 new=20

• 日志先写入日志文件（通常是顺序写）
• 日志刷盘（fsync）

4. 提交事务

COMMIT

• 写一条 Commit 日志记录
• 确保 Commit 日志已落盘

5. 后台异步刷数据页

• 数据页稍后被后台线程刷到磁盘
• 不阻塞事务提交

五、崩溃后的恢复过程

系统重启时，WAL 用于恢复：

1. Redo（重做）

• 从最后一个检查点（Checkpoint）开始
• 重放所有已提交事务的日志
• 保证“该有的修改都在”

2. Undo（回滚）

• 对未提交但已写入日志的事务
• 使用 Undo 信息回滚
• 保证“不该有的修改被撤销”

六、Checkpoint 的作用

如果一直不清理 WAL：

• 日志会无限增长
• 恢复时间变长

Checkpoint（检查点）：

• 把内存中已修改的数据页刷盘
• 记录“到此为止的日志已安全”
• 之后的日志可以从新点开始

七、WAL 为什么快

• 日志是顺序写（很快）
• 数据页是随机写（很慢）
• 事务提交只需等日志落盘，不等数据落盘

八、典型使用 WAL 的系统

• PostgreSQL（WAL）
• MySQL InnoDB（Redo Log + Binlog）
• SQLite（WAL 模式）
• LevelDB / RocksDB（WAL）
• Kafka（类似思想）

九、一句话总结

WAL 通过“先记日志、后改数据”的方式，用顺序写换取了崩溃安全和高性能。

如果你愿意，我也可以用一张流程图或PostgreSQL / InnoDB 的具体例子来进一步说明。