【数据存储】SQLite WAL 模式：读写并发实测与开启方法

实战应用：用在哪里

SQLite 默认的回滚日志模式在写入时会阻塞读取（写锁独占），游戏服务端“边写日志边查配置”的场景会出现周期性查询变慢。WAL（Write-Ahead Logging）模式把读写分离：写入追加到 WAL 文件，读取不阻塞，实测同库并发读写的吞吐提升数倍。

开启与验证

PRAGMA journal_mode = WAL;       -- 返回 wal 即开启成功
PRAGMA synchronous = NORMAL;     -- WAL 下推荐的安全级别
PRAGMA wal_checkpoint(TRUNCATE); -- 手动触发检查点，收缩 WAL 文件

开启后同一连接的写入不再阻塞其他连接的读取。WAL 文件（-wal 后缀）会持续增长，由检查点机制定期合并回主库——自动检查点默认在 1000 页时触发，高频写入场景可以调低阈值。

实测对照

测试场景：4 个连接并发（2 写 2 读），写入每秒 200 条、读取每秒 50 次查询，各跑 5 分钟：

读取端收益是主要来源：WAL 下读取完全不等待写入。

三个运维细节

WAL 模式的库由主库 + -wal + -shm 三个文件组成，备份时三个文件要一起拷贝（或先做检查点再只备主库）；跨机器迁移后首次打开前确认三个文件完整；读写分离的多连接场景，写入连接数建议控制为 1（多个写连接会互相等待写锁）。开启后用并发压测复核一遍读写耗时，确认模式切换达到预期。

checkpoint 的调优参数：wal_autocheckpoint 默认一千页，高频写入的库可以把阈值调低让 WAL 文件保持小巧，代价是更频繁的合并。观察 WAL 文件体积的日曲线，持续增长说明检查点频率不足或存在长读事务阻塞合并。长读事务期间 WAL 无法收缩，把大查询挪到低峰或拆分执行，WAL 体积就会回落。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。