SQLite WAL文件是否会自行缩小或重置体积？

嘿，针对你提到的SQLite WAL文件体积和手动检查点的问题，我来给你拆解清楚👇

一、WAL文件会不会自行重置体积？ #

先给你明确结论：默认情况下，SQLite不会主动把WAL文件体积直接缩减到零，但它会在特定条件下自动复用或截断WAL空间。具体细节是这样的：

• 当WAL文件里的页面数量达到checkpoint_full_page_count（默认1000页，可通过PRAGMA checkpoint_full_page_count查看/修改）时，SQLite会自动执行「被动检查点」（PASSIVE模式）——把WAL里的内容合并回主数据库，但WAL文件体积不会缩小，后续写入会直接覆盖旧的页面空间。
• 只有当所有数据库连接都关闭，且没有未提交的活跃事务时，SQLite才会自动触发检查点并将WAL文件截断到最小尺寸（通常是0或者极小的大小）。如果还有其他连接保持打开，单个连接关闭不会触发这个截断操作。

说白了：日常使用中WAL会保持现有体积循环复用，只有彻底关闭所有连接且无残留事务时，才会自动“重置”体积。

二、关于PRAGMA wal_checkpoint(TRUNCATE)的常见问题 #

你提到在程序初始阶段执行这个命令遇到问题，大概率是踩了这些常见坑：

• 时机不对：程序刚创建数据库还没写入任何数据时，WAL文件根本不存在，执行这个命令自然没有效果。得等有写入操作完成、且无活跃事务时再执行。
• 存在活跃事务或其他连接：TRUNCATE模式的检查点需要等待所有未提交的事务完成，要是有其他连接正在写数据库，要么会超时，要么直接执行失败。可以先通过PRAGMA busy_timeout = 3000;设置超时时间，或者确保执行检查点时没有其他写操作在运行。
• 未提交事务：如果你的写入程序在执行检查点时还有没提交的事务，WAL里的内容无法被合并回主库，TRUNCATE自然不会生效。记得先执行COMMIT;提交所有未完成的事务，再跑检查点命令。

给你一个靠谱的执行流程示例：

-- 先提交所有未完成的事务
COMMIT;
-- 执行截断式检查点，缩减WAL体积
PRAGMA wal_checkpoint(TRUNCATE);

如果你想更省心，也可以把PRAGMA wal_autocheckpoint设为更小的值，让SQLite更频繁地自动执行检查点；或者在批量写入完成这类特定阶段主动触发TRUNCATE，而不是在程序初始化阶段操作。

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