运行 SQLite 的学习心得2026 年 7 月 17 日我在开发一个 Django 网站时决定使用 SQLite 作为数据库。开始时我读了很多关于在小型网站生产环境中使用 SQLite 没问题的博客文章我也认同这一点。但我没充分意识到SQLite 作为数据库本身很复杂而我对数据库运维了解不多。这是我第四次在网站中使用 SQLite这次借助 Django ORM 的强大功能让数据库承担的工作比以前更多更具挑战性。我一开始按博客建议开启了 WAL 模式然后就听天由命了。1. ANALYZE 很重要今天我在一个有 4000 行数据的表上执行查询用 SQLite 的 FTS5 进行全文搜索花了 5 秒钟这显然不对劲。后来发现需要运行 ANALYZE 命令执行后有问题的查询时间从 5 秒缩短到大约 0.05 秒。我不太清楚查询计划具体问题在哪猜测可能是意外的平方复杂度问题。ANALYZE 会生成“统计信息”让查询规划器做出更优选择。也许有一天我会学会解读查询计划。2. 清理数据库很棘手偶尔我会不小心往数据库插入不想要的行比如 django - tasks - db 里已完成的任务然后想清理它们。这时会遇到问题我运行清理命令因行数多命令执行超 5 秒期间其他工作进程试图写入数据库5 秒后超时工作进程因无法写入数据库崩溃虚拟机关闭。目前我的解决办法是分小批量清理避免执行耗时超 5 秒的数据库查询。这段经历让我理解为什么有人想用像 Postgres 这样的“真正”数据库。也许将来我进行这类操作时会让网站停机定期维护但还没摸索出工作流程。3. 目前未关注 ORM 查询性能到目前为止我用 Django 的 ORM 随心所欲执行查询没关注性能除 ANALYZE 那次外基本顺利。数据库规模小大概 10000 行数据且预计会一直保持我希望这个策略能一直奏效。4. 备份 SQLite我采用过几种方式备份 SQLite 数据库没测试过从备份中恢复数据但用失效保护机制监控备份情况。方式一使用 restic。操作步骤为sqlite3 /data/calendar.db VACUUM INTO /tmp/calendar.sqlite; gzip /tmp/calendar.sqlite上传备份到 S3有时备份会因内存不足被终止需解锁文件执行备份并清理旧备份。方式二使用 Litestream。最近我开始尝试因为觉得增量备份更高效restic 备份有时会因内存不足终止。我只需编写配置文件然后运行litestream replicate - config litestream.yml。我在配置文件中设置了 retention: 400h但不知是否有效。我一直将数据备份到 AWS这很麻烦也许有一天我会迁移到其他兼容 S3 的替代方案。5. 可以使用多个数据库我目前项目只有一个数据库但在 Mess with DNS 项目中我把表拆分成三个独立的数据库文件因为不需要把所有表放在同一个数据库里我觉得这样做很有帮助。Mess with DNS 从 2022 年开始在 SQLite 上运行至今 4 年效果非常好我认为从 Postgres 迁移过来是明智选择。6. 总结与展望看着自己花时间才学会所使用技术的基础知识挺有趣我 2022 年第一次在 Web 项目中使用 SQLite今天才知道 ANALYZE 命令。我猜再过一两年又会学到其他基础功能。