SQLite 数据库本身没变大，旁边的 -wal 文件却持续增长。先分清文件已经留在磁盘上等待复用，还是新写入一直无法合并，再决定怎么处理。
先看趋势和运行模式
对同一数据库路径分时记录主文件、-wal 文件大小和分区余量，在现有连接上通过PRAGMA journal_mode;确认模式。文件大而稳定，和文件不断增长，是两种现象。成功的 checkpoint 也不一定马上缩小 WAL。
理解 checkpoint 的三列结果
在获得维护许可后，可在代表性数据库执行PRAGMA wal_checkpoint(PASSIVE);并记录返回值。后两列分别是 WAL 帧数和已回写帧数；在非 WAL 模式等情况下可能返回负值。这条语句会尝试回写，并非纯查询。PASSIVE 不等待其他连接，也不要用第一列为零推断所有帧都已回写。
检查长期占住快照的读事务
长读事务可能阻止 checkpoint 完成；检查应用是否跨网络调用保留事务、游标是否及时关闭及连接池是否归还连接。SQLite 没有服务器端会话视图可直接列出所有读事务。应从应用日志和事务生命周期定位。
维护窗口再考虑截断
先处理读事务和写入速率，再在隔离环境评估PRAGMA wal_checkpoint(TRUNCATE);。它成功时可将 WAL 截断到零，但可能等待并影响工作负载。切勿手动删除正在使用的 -wal 或 -shm 文件。已提交的数据可能仍在 WAL 内。
用峰值流量下的趋势验收
可在萤光云或LightNode的独立实例用备份演练：观察正常写入时 WAL 是否能重复利用，结束长读事务后回写是否追上，应用的读写延迟是否保持在可接受范围。验收以文件不再无界增长和业务正常为准。
FAQ
WAL 大一定说明未回写吗？ 不一定，SQLite 可保留文件空间复用。
缩短自动回写阈值能解决长读事务吗？ 不能解除读事务持有的快照。
能只复制主库文件备份吗？ 在线时应使用可靠的 SQLite 备份方式。
PASSIVE 会等长事务吗？ 不会等待其他连接释放。
回写能替代备份吗？ 不能。
温馨提示
磁盘余量已很低时，先控制写入并扩大可用空间。用应用实际链接的 SQLite 版本核对官方文档，避免仅用系统命令行版本判断。
