分享一些实战经验与教训。在一个 Django 项目中选用了 SQLite 作为数据库，需要明确的是，“小型生产站点可以使用 SQLite”这句话，并不代表你可以完全忽略数据库的日常运维。Django 的 ORM 实际上会让数据库承受更多负载，仅开启 WAL 模式，远远无法解决查询规划、常规维护以及并发写入带来的全部挑战。

首先来看一个最典型的案例。一个基于 FTS5 全文搜索的查询，处理大约 4,000 行数据，耗时约 5 秒。在执行 ANALYZE 之后，查询时间骤降至惊人的 0.05 秒。原因很简单：ANALYZE 会生成详细的统计信息，帮助查询规划器选择更优的执行路径。即使你完全看不懂执行计划，这一维护步骤也能消除大量意料之外的低效路径。这种性能差距，熟悉数据库的人自然明白意味着什么。

类似的问题在数据清理过程中同样会出现。大量删除无用行会引发一个实际风险：当一个耗时较长的 DELETE 语句在事务中执行时，其他 worker 如果尝试写入数据，并且设置了 5 秒超时，就很可能导致写入失败甚至进程崩溃。值得强调的是，这并不是劝退大家使用 SQLite，而是想突出一个核心观点：将长事务、超时配置、维护窗口以及查询统计等要素一并纳入你的运行策略。当负载逐渐增长时，持续观察系统的边界在哪里，远比事后补救更为重要。