你好！最近我一直在处理一个Django网站，并决定使用SQLite作为数据库。当我开始使用SQLite作为网站数据库时，我阅读了一些博客文章，关于在小型网站上使用SQLite完全没问题，我认为这确实没有问题，但我没有完全意识到的是，SQLite仍然是一个数据库，数据库是复杂的，而我对操作数据库了解不多。所以在这里，我分享一些我学习到的关于运行SQLite的小知识。这是我使用SQLite的第四个网站，我觉得这个比较困难，因为在Django ORM的强大功能下，我让数据库做了比之前没有Django时更多的工作。我首先像所有博客文章所说的那样开启了WAL模式，并希望会有好的结果。ANALYZE显然很重要今天我在一个有4000行的表上运行了一个查询（使用SQLite的FTS5进行全文搜索），花费了5秒钟。这让我觉得不对劲：计算机是快的！事实证明，我需要做的是运行ANALYZE！立即，问题查询的时间从5秒降到了0.05秒（或者其他一个足够小的数字，我就没再深究）。我仍然不知道查询计划到底出了什么问题，但我猜测可能是某种意外的二次复杂度。ANALYZE生成“统计信息”（我猜是关于每个表中的行数？还有可能是其他东西？），这样查询规划器就能做出更好的选择。也许有一天我会学习如何解读查询计划。清理数据库是棘手的我偶尔会遇到一些情况，我不小心将一些不想在数据库中的行放入其中（例如来自django-tasks-db的已完成任务），我想要清理它们。在这种情况下，我碰到过几次：我运行某种清理行的命令，该命令花费超过5秒，因为有很多行（尽管我仍然对为什么这些DELETE语句处理得如此缓慢感到疑惑，可能是因为在一个事务内运行了大量的Python代码，我不确定）。其他工作者在此期间尝试写入数据库，然后在5秒后超时（我的超时时间设置为5秒）。工作者因为无法写入数据库而崩溃，虚拟机关闭。到目前为止，我的方法是以小批量进行这些清理操作，这样就无需执行超过5秒的数据库查询。整个经历让我更加领悟到，为什么有些人可能想使用“真正的”数据库，比如Postgres，它可以同时有多位写入者。也许将来我会在需要做这种事情时将网站停下进行定期维护，但我还没有找到一个合适的工作流程。至今没有关于ORM查询性能的笔记到目前为止，我一直在使用Django的ORM进行任何查询，而没有关注查询性能，除了ANALYZE的事情之外，整体上都还算顺利。数据库相当小（可能10000行？），我预计它会一直保持相对小，所以我希望这个计划能继续有效。SQLite备份我进行SQLite备份的方式有几种。我不认为我实际上测试过从备份中恢复，但我通常会努力用一个死人开关来监控它们。方式1：restic sqlite3 /data/calendar.db "VACUUM INTO '/tmp/calendar.sqlite'" gzip /tmp/calendar.sqlite # 将备份上传到S3 # 有时备份会被OOM杀死，因此保持锁定，进行解锁 restic -r s3://s3.amazonaws.com/some_bucket/ unlock # 进行备份并修剪旧备份 restic -r s3://s3.amazonaws.com/some_bucket/ backup /tmp/calendar.sqlite.gz restic -r s3://s3.amazonaws.com/some_bucket/ snapshots restic -r s3://s3.amazonaws.com/some_bucket/ forget -l 1 -H 6 -d 2 -w 2 -m 2 -y 2 restic -r s3://s3.amazonaws.com/some_bucket/ prune 方式2：litestream 我最近开始尝试使用Litestream，因为我觉得增量备份可能更有效：我的restic备份有时会被OOM杀死，我对此有点疲惫。基本上我只需编写一个配置文件并运行： litestream replicate -config litestream.yml 我在配置文件中设置了retention: 400h，试图保留一些数据库历史记录，但我不知道是否有效。我一直在备份到AWS，这总是很麻烦，因为在AWS控制台上生成凭据令人烦恼。也许有一天我会转向其他兼容S3的替代方案。你可以使用多个数据库我的当前项目只有一个数据库，但我在Mess with DNS中应用的一个技巧是将表分成三个独立的数据库文件，因为我实际上不需要我的表在同一个数据库中。我认为这样做是有帮助的。Mess with DNS自2022年以来一直在SQLite上运行，效果很好。