用SQLite当本地缓存时那些容易忽略但又挺重要的点你知道吗

很多人选择SQLite做缓存是看中了它的轻量、无需部署和零配置，但正是这种“开箱即用”的错觉，导致了一些问题在后期才爆发，根据SQLite官方文档和许多开发者的实践经验，以下几点需要特别注意。

第一点：写操作的并发瓶颈与WAL模式

这是一个最经典也最容易踩坑的地方,SQLite在默认情况下，同一时间只允许一个写操作进行，这意味着，如果你的应用有多个线程或多个进程同时尝试向缓存中插入或更新数据，他们会排起队来，一个接一个地执行，在高并发写的场景下，这会导致性能急剧下降，甚至出现“数据库被锁定”的错误。

解决方案是启用“预写日志”模式，也就是WAL模式，根据SQLite官方文档介绍，WAL模式彻底改变了处理并发的方式，在WAL模式下，读操作和写操作可以同时发生，写入者将修改内容先写入一个单独的WAL文件，而读者则继续从主数据库文件中读取旧的数据，这种机制大大提升了并发性能，启用WAL非常简单，只需要在执行任何数据库操作之前，发送一条SQL命令：PRAGMA journal_mode=WAL;，不过需要注意的是，WAL模式在极少数多进程并发写的场景下可能会有一些复杂性，但对于绝大多数单进程多线程的应用程序来说，它是提升性能的利器。

第二点：缓存的大小管理与自动清理

既然是缓存,就不可能让数据无限增长，你必须有策略地清理旧数据，否则数据库文件会越来越大，影响读写速度，并占用过多磁盘空间，很多人会想到用DELETE语句来删除旧记录，但这只是第一步。单纯执行DELETE并不会释放磁盘空间给操作系统，SQLite只是将那些被删除数据所占用的页标记为“可重用”。 数据库文件的大小并不会缩小。

要真正回收空间,你需要执行VACUUM命令，但VACUUM是一个重量级操作，它会重建整个数据库文件，在此期间会占用大量CPU和磁盘I/O，并独占数据库锁，导致服务暂时不可用，不能频繁执行。

更优雅的做法是结合使用DELETE和PRAGMA auto_vacuum，SQLite提供了自动真空模式，虽然默认是关闭的，但你可以设置为增量真空或全自动真空，全自动真空会在每次事务提交后尝试回收空间，但有一定开销，更常见的做法是定期（比如每天凌晨）执行一次VACUUM，或者在应用启动时判断数据库文件大小，如果超过某个阈值则触发清理，设置一个合理的PRAGMA page_size（页大小）也能影响空间利用效率。

第三点：事务的正确使用

很多人觉得缓存操作都是小打小闹,直接执行单条INSERT或UPDATE就行了，忽略了事务，这是一个巨大的性能陷阱。如果你需要一次性插入或更新大量缓存项（比如1000条），而每条都用一个独立的事务，那么SQLite需要为每一条数据执行昂贵的磁盘同步操作（除非你禁用了安全设置），这会极其缓慢。

正确的做法是显式使用事务块,将大量的写操作包裹在BEGIN TRANSACTION; 和 COMMIT; 之间，这样，所有的修改会被组织成一个大的事务，SQLite只需要在最后提交时进行一次磁盘同步，性能会有数量级的提升，根据SQLite官方测试，使用事务可以将批量插入的速度提升数百甚至上千倍。

第四点：灵活的缓存失效策略

缓存数据不能永远有效,你需要设计失效机制，除了上面提到的基于时间的清理（比如只保留最近7天的数据）和基于空间的清理（缓存满后淘汰最旧的数据LRU），还有一个重要但常被忽略的点：应用层事件的触发式失效。

举个例子,你的应用缓存了用户A的个人信息，当用户A在另一个设备上修改了自己的头像和昵称后，当前设备本地缓存的数据就过期了，如果只依赖时间过期，可能用户要等很久才能看到更新，这时，理想的方式是服务端在数据变更时，通过消息推送等方式通知客户端：“用户A的信息已变更，请失效本地缓存”，客户端收到通知后，主动删除对应的缓存条目，下次需要时，自然会从服务端拉取最新数据，这种推拉结合的机制能极大提升缓存的准确性和用户体验。

第五点：应对数据库损坏与版本迁移

虽然SQLite非常稳定,但在极端情况下（如设备断电、磁盘错误、程序崩溃时正在写入），数据库文件依然有微小概率损坏，你不能假设它100%可靠。应用程序应该具备一定的容错和修复能力。 一种简单的做法是在应用启动时，执行PRAGMA integrity_check;或PRAGMA quick_check;来快速检查数据库是否完好，如果发现损坏，最直接的办法是删除旧的数据库文件，然后重新从零开始构建缓存，这就要求你的缓存机制不能是“唯一数据源”，源数据必须来自网络或其它可靠地方。

当你的应用升级,缓存的数据结构需要改变时（比如增加一个字段），就涉及到数据库 schema 的版本迁移，你绝对不能直接删除旧库了事，因为可能用户在没有网络的情况下打开了应用。你必须使用SQLite提供的user_version这个PRAGMA来管理数据库版本号，并在代码中实现从旧版本到新版本的迁移逻辑，比如用ALTER TABLE语句来添加列，确保平滑升级。

总结一下，把SQLite当作缓存，不能只是简单地“存进去、读出来”，你需要像对待一个严肃的持久化存储一样，关注它的并发性能（WAL模式）、空间管理（VACUUM与清理策略）、操作效率（事务）、数据新鲜度（失效策略）和健壮性（损坏处理与版本迁移），考虑到这些细节，才能让这个轻量级的数据库引擎在你的应用中稳定、高效地发挥作用。