未执行VACUUM，SQLite3为何自动回收空间？

核心原因：SQLite的页复用与自动截断优化 #

当你将大二进制列替换为压缩后的数据时，新数据占用的存储空间远小于原数据。SQLite 3.28.0及以后版本引入了一项默认优化：即使auto_vacuum设为0，只要数据库末尾的连续页变为空闲状态，SQLite会自动截断文件，回收这些末尾的空闲空间。

你的场景中，最大表的大量二进制数据被压缩后，原数据占用的末尾连续页全部变成空闲，触发了这个自动截断逻辑，因此数据库文件大小直接缩减到了符合压缩率的数值——这完全是新版本SQLite的正常特性，并非异常行为。

潜在风险排查 #

• 关于引用关系破坏：你之前遇到的VACUUE问题是因为该命令需要重建整个数据库，可能因旧版本bug或特殊索引/触发器引发关联异常；但本次的自动截断仅移除文件末尾的空闲页，不会修改数据库内部的页结构或行引用，因此不会破坏数据关联。
• 数据完整性验证：可执行以下命令确认数据状态：

  PRAGMA integrity_check;
  PRAGMA foreign_key_check;
  

  若返回ok，则说明数据完全正常。
• auto_vacuum参数的作用：该值为0仅禁用碎片化空闲页的自动移动回收，但不影响末尾空闲页的自动截断——这是独立于auto_vacuum的优化逻辑。

总结 #

这是SQLite 3.28+版本的正常优化特性，无需执行VACUUM即可自动回收末尾空闲空间，且操作比VACUUM更安全，不会修改数据库内部布局。只要通过完整性检查确认数据无误，就无需担忧。

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