内存SQLite数据库是否需要执行VACUUM？多线程场景执行有何影响？

1. 内存SQLite的碎片问题与VACUUM必要性 #

• 内存SQLite同样会产生存储碎片：SQLite采用统一的页式存储管理逻辑，磁盘库和内存库的底层存储逻辑一致。频繁执行增删改操作时，被删除的数据占用的内存页不会直接释放给操作系统，只会被SQLite标记为空闲页等待复用。当存在大量不连续的空闲页、或部分填充页时，就会形成内存碎片，表现为实际存储数据量极小，但SQLite占用的总内存持续上涨，不属于常规内存泄漏。
• 内存SQLite支持VACUUM操作，且对你的场景非常必要：VACUUM会将所有有效数据重写到连续的新内存空间，同时释放所有未被使用的空闲页，执行后内存占用会回落至和实际数据量匹配的水平。你当前场景数据总大小只有几KB，单次VACUUM执行耗时通常在微秒级，对业务的影响极小。

2. 多线程共享场景下的VACUUM执行行为 #

• 其他连接的等待逻辑：VACUUM执行期间会持有数据库的排他锁，默认配置下其他线程的读写操作都会进入阻塞状态，直到VACUUM执行完成、排他锁释放后才会恢复运行，不会直接抛出错误。
• 存在活跃事务时的表现：如果启动VACUUM时其他线程持有未提交的活跃事务，VACUUM申请排他锁会失败，直接返回SQLITE_BUSY错误，不会强行中断正在运行的事务。你可以通过PRAGMA busy_timeout = 超时毫秒数;配置锁等待超时时间，让VACUUM申请锁时等待指定时长，超时后才返回失败。
• 适配多线程场景的优化方案：你可以开启增量自动清理模式，执行PRAGMA auto_vacuum = INCREMENTAL;，开启后SQLite会在每次删改操作后自动回收部分空闲页，不需要手动执行全量VACUUM，对业务的阻塞影响会大幅降低。

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