SQLite 学习笔记（四）：深入解析 SQLite WAL 原理

目录#

传统日志模式（DELETE模式）的瓶颈
什么是 WAL 模式？
WAL 模式的核心原理
WAL 模式的优点与缺点
- 4.1 优点
- 4.2 缺点
启用与配置 WAL 模式
- 5.1 启用 WAL
- 5.2 相关 PRAGMA 指令
最佳实践与常见问题
总结
参考资料

传统日志模式（DELETE模式）的瓶颈#

在深入 WAL 之前，有必要了解其要解决的问题。在默认的 DELETE 模式下：

写入时独占锁：当一个连接要写入数据库时，它必须获得数据库文件的独占锁（EXCLUSIVE LOCK）。
读者阻塞写者，写者阻塞所有：在独占锁被持有期间，其他任何连接（无论是读还是写）都无法访问数据库。这意味着一个长时间的写入操作会阻塞所有其他操作。
回滚日志：写入过程涉及创建回滚日志、将修改的原始数据页写入日志、修改数据库主文件、最后删除日志文件。这个过程涉及多次磁盘同步（fsync），效率较低。

这种模式在并发要求高的场景下（如 Web 服务器、多线程应用）会成为严重的性能瓶颈。

什么是 WAL 模式？#

WAL 模式的核心思想源于日志先行（Write-Ahead Log）原则，但与传统的实现方式有根本区别。其核心逆转是：

修改不再直接写入主数据库文件，而是追加到一个单独的、顺序写的日志文件（WAL 文件）中。读操作可以同时看到主数据库文件和 WAL 文件中的内容，从而组合出当前数据库的一致状态。

这种“读旧数据，写新日志”的方式，天然地实现了读写并发。

WAL 模式的核心原理#

3.1 两个关键文件：WAL 文件和 SHM 文件#

启用 WAL 模式后，数据库目录下会出现两个新文件：

<database-name>-wal：预写日志文件。这是 WAL 模式的核心。所有的事务提交（COMMIT）内容都以帧（Frame） 的形式追加到该文件末尾。每个帧对应数据库的一个页（Page） 的修改内容。WAL 文件是循环使用的。
<database-name>-shm：共享内存文件。这是一个临时索引文件，用于管理 WAL 文件的访问。它存储了 WAL 文件的元数据，如各个读连接当前读取的位置、检查点信息等。所有连接到同一个数据库的进程通过这个文件来协调对 WAL 的访问。

3.2 写操作（Write）流程#

开始事务：连接开始一个写事务。
获取写锁：在 WAL 模式下，写入者只需要获取一个写锁（WAL WRITE LOCK），这个锁的粒度非常小，只用于保护对 WAL 文件末尾的追加操作。
修改页并写入 WAL：事务中对数据库页的修改，并不会直接写回主数据库文件（*.db），而是将修改后的整个页作为一个帧（Frame），连同帧头信息（如页号、校验和等）一起追加到 WAL 文件的末尾。这个过程是顺序写，对于磁盘（尤其是机械硬盘）来说，效率远高于随机写。
提交事务：当事务提交时，只需要确保所有修改页的帧都已写入 WAL 文件并同步到磁盘（如果设置了 synchronous=FULL）。一旦 WAL 文件写入成功，事务就算提交成功。
释放写锁：写入者立即释放 WAL 写锁。这个锁持有的时间非常短，仅覆盖步骤 3 和 4，因此其他读写操作被阻塞的时间极短。

3.3 读操作（Read）流程#

这是 WAL 模式性能提升的关键：

读取最新提交标记：读连接首先会读取 WAL 文件中的一个特殊标记，以确定最后一次成功提交的事务在 WAL 文件中的位置。这个位置被称为 结束标记（End Mark）。
组合数据视图：读操作开始执行。当需要读取某个页时（例如页 #X），它按以下顺序查找：
- 先查找 WAL 文件：从 WAL 文件的末尾向开头扫描（因为最新的修改在最后），寻找包含页 #X 的最新帧。
- 如果找到：则使用 WAL 帧中的页内容。
- 如果没找到：则从主数据库文件（*.db）中读取页 #X 的原始内容。
获得一致性快照：通过这种方式，每个读连接都能看到在它开始读取那一刻之前所有已提交的事务，而完全不会被后续的写事务阻塞。这相当于实现了一个读未提交（Read Uncommitted）或可重复读（Repeatable Read） 级别的事务隔离。

3.4 检查点（Checkpointing）流程#

由于写入操作只修改 WAL 文件，主数据库文件会逐渐变得过时。为了控制 WAL 文件的大小并将修改持久化到主文件，需要一个后台过程：检查点（Checkpoint）。

目的：将 WAL 文件中已提交的修改回填到主数据库文件中，并截断（重置）WAL 文件。
触发条件：
- 自动触发：当 WAL 文件大小超过预设阈值（默认为 1000 页，约 4MB）时，SQLite 会在写事务提交时自动尝试进行检查点。
- 手动触发：通过 PRAGMA wal_checkpoint 命令手动执行。
- 被动触发：当最后一个数据库连接关闭时，会执行一个完整的检查点。
过程：
1. 检查点进程会获取一个短暂的锁，阻止新的写事务开始。
2. 它将 WAL 文件中所有已提交的、且尚未写入主数据库的页，批量写回主数据库文件。这通常是顺序写，效率较高。
3. 更新主数据库文件的文件头，以反映检查点完成的状态。
4. 最后，可以安全地截断 WAL 文件。

WAL 模式的优点与缺点#

4.1 优点#

读并发性极大提升：读者和写者大部分时间可以并行工作，这是最大的优势。
写性能更高：写入 WAL 文件是顺序写，通常比随机写主数据库文件更快。在事务提交时，可能只需要一次 fsync（对于 synchronous=FULL）。
更快的磁盘同步：在某些平台上，对同一文件（WAL文件）的多次 fsync 可能比对不同文件（主数据库和回滚日志）的 fsync 更高效。

4.2 缺点#

需要共享内存（SHM文件）：所有数据库连接必须在同一台主机上，能够访问相同的共享内存文件。这意味着 WAL 模式不能用于网络文件系统（NFS） 上的数据库。
数据库文件格式变化：启用 WAL 后，数据库文件格式被永久提升，无法被 3.7.0 之前的 SQLite 版本读取。
检查点开销：如果写入非常频繁，检查点操作可能成为新的瓶颈。需要合理配置检查点策略。
VACUUM 操作更复杂：在 WAL 模式下，VACUUM 命令需要先切换回 DELETE 模式，执行完毕后再切换回 WAL。

启用与配置 WAL 模式#

5.1 启用 WAL#

在打开数据库连接后，执行一条简单的 PRAGMA 命令即可：

PRAGMA journal_mode = WAL;

如果成功，该查询会返回 wal。

5.2 相关 PRAGMA 指令#

PRAGMA synchronous：控制何时将数据同步到磁盘。在 WAL 模式下，NORMAL 选项比 DELETE 模式下更安全，因为崩溃不会损坏数据库，但可能丢失最近提交的事务。FULL 是最安全的。
```
PRAGMA synchronous = NORMAL; -- 性能更好，可能丢失事务
PRAGMA synchronous = FULL;   -- 最安全，性能稍差
```
PRAGMA wal_autocheckpoint：设置自动触发检查点的 WAL 文件页数阈值。
```
PRAGMA wal_autocheckpoint = 1000; -- 默认值（约4MB）
```

手动执行检查点：

PRAGMA wal_checkpoint; -- 尽力而为，可能不会截断WAL
PRAGMA wal_checkpoint(PASSIVE); -- 同上
PRAGMA wal_checkpoint(TRUNCATE); -- 执行检查点并截断WAL文件
PRAGMA wal_checkpoint(RESTART); -- 执行检查点并重置WAL文件

最佳实践与常见问题#

何时使用 WAL？
- 强烈推荐：大多数需要并发读写的应用程序，特别是多线程应用和Web应用。
- 不推荐：数据库文件位于网络驱动器（NFS）上，或者应用程序只有单线程串行访问。
处理 “database is locked” 错误
- 在 WAL 模式下，这个错误通常是由于写事务之间的冲突，而不是读-写冲突。
- 使用超时重试机制是处理此问题的标准做法。SQLite 默认的 busy_timeout 就可以很好地处理。
检查点管理
- 对于写入密集型应用，可以调高 wal_autocheckpoint 阈值，减少检查点频率，但会增大 WAL 文件。
- 也可以在应用空闲期（如夜间）手动执行 PRAGMA wal_checkpoint(RESTART) 来重置 WAL 文件。
事务大小
- 与任何数据库一样，将大的写操作分解为多个较小的事务，有助于减少单个写锁的持有时间，提升整体并发性。
备份
- 在 WAL 模式下，直接复制 *.db 文件是不完整的，必须同时复制 *-wal 文件。
- 推荐使用 SQLite 的在线备份 API (sqlite3_backup_init) 或 .dump 命令进行热备份。

总结#

SQLite 的 WAL 模式通过将“写主文件”转变为“写日志文件”，巧妙地解决了读写锁竞争的问题。它允许多个读连接与一个写连接并行工作，极大地提升了并发性能。虽然它引入了新的概念（WAL文件、检查点）和一定的复杂性，但其带来的性能收益在绝大多数应用场景下都是值得的。理解其原理有助于开发者更好地配置、监控和优化基于 SQLite 的应用程序。

目录#