Write-Ahead Logging（WAL）工作原理及数据一致性保障解析

首先明确：WAL在合并（检查点）过程中不需要额外的回滚日志，其一致性完全依赖WAL自身的结构、锁机制和原子性的元数据更新。下面拆解核心逻辑：

检查点的核心逻辑 #

检查点的本质是把WAL文件中已提交的事务修改，批量写入主数据库文件，同时保证主库和WAL的状态始终一致。关键步骤和保障机制如下：

1. 锁与并发控制 #

SQLite提供四种检查点模式（PASSIVE、FULL、RESTART、TRUNCATE），不同模式对应不同的锁策略：

• PASSIVE：不阻塞写入事务，仅在WAL无新写入的间隙完成合并，适合低延迟场景。
• FULL/RESTART：会获取WAL的排他锁，短暂阻止新的写入事务，确保合并过程中WAL的内容不会被修改，避免并发写入导致的冲突。

2. 分步写入与原子性元数据更新 #

检查点不会一次性把所有WAL内容写入主库，而是分阶段执行：

• 首先遍历WAL中已提交的事务对应的页面，逐个写入主数据库文件。这一步即使中途崩溃，主库可能存在部分更新的页面，但这些页面的最新版本仍然保存在WAL中。
• 所有页面写入完成后，原子性地更新WAL文件的头部信息，标记哪些WAL帧（frame）已经合并到主库。这一步是关键：只有头部更新完成，检查点才算真正完成。

如果合并中途崩溃，下次启动时SQLite会读取WAL头部，发现检查点未完成，此时会忽略主库中未被标记合并的页面更新，直接从WAL读取最新的提交数据，然后重新执行检查点，最终保证主库和WAL的状态一致。

3. WAL自身的持久性保障 #

WAL文件是追加写入的，所有事务修改都是按顺序追加到WAL末尾，这种写入方式在磁盘上是原子性的（磁盘追加写通常不会出现部分写入的情况）。因此，只要WAL文件本身未损坏，所有已提交的事务记录都是完整的，这为检查点的恢复提供了可靠的数据源。

与回滚日志的本质区别 #

回滚日志是"先写旧数据"：修改主库前先把原始数据存入日志，崩溃时用日志恢复主库到修改前的状态。而WAL是"先写新数据"：所有修改先写入WAL，主库的更新是异步的合并操作。WAL本身就充当了"正向"的恢复日志，不需要额外保存旧数据——因为如果合并失败，最新的正确数据仍然在WAL里，主库的不完整更新会被直接忽略。

内容的提问来源于stack exchange，提问作者Zebrafish