生产环境遇到 SQLite 查询慢，最安全且直接的手段是使用 EXPLAIN QUERY PLAN 查看执行计划，它能在不实际执行查询的情况下展示数据库的访问路径，帮助你判断是否命中索引。
先说结论：在生产环境分析慢查询时，优先使用 EXPLAIN QUERY PLAN 而非直接执行查询，通过观察输出中的 SCAN 或 SEARCH 关键字来定位是否缺少索引。
- 先定位：对慢查询语句添加 EXPLAIN QUERY PLAN 前缀，获取执行路线图。
- 先做：检查输出中是否出现 SCAN TABLE，若有则考虑针对 WHERE 条件字段建立索引。
- 再验证：建立索引后再次运行命令，确认计划变为 SEARCH TABLE 或 USING INDEX COVERING。
命令速用版
在 SQLite 命令行或客户端工具中，直接在原查询语句前加上 EXPLAIN QUERY PLAN 即可：
EXPLAIN QUERY PLAN SELECT * FROM orders WHERE user_id = 123 AND status = 'shipped';
该命令不会真正读取数据行，只会返回查询引擎计划的访问步骤，对生产库安全。
为什么会这样
SQLite 查询慢通常是因为数据库引擎选择了低效的数据访问方式。EXPLAIN QUERY PLAN 相当于给查询过程拍了一张“X 光片”，它展示了引擎准备如何查找数据。
如果输出显示 SCAN TABLE，意味着引擎准备逐行扫描整个表，这在数据量大时是性能杀手。如果显示 SEARCH TABLE USING INDEX，说明引擎打算利用索引直接定位数据，效率通常更高。理解这个区别是优化的第一步，盲目添加索引而不看计划，可能会引入新的维护成本却未解决实际问题。
分步处理
1. 捕获慢查询语句：从应用日志或监控系统中找到执行时间较长的 SQL 语句。
2. 生成执行计划：在测试环境或只读副本上，对该语句执行 EXPLAIN QUERY PLAN。注意不要在生产主库上频繁执行复杂查询的 EXPLAIN，虽然它不返回数据，但仍会消耗少量解析资源。
3. 解读关键算子：查看输出结果中的关键字。
- SCAN TABLE：全表扫描，通常意味着缺少索引或索引失效。
- SEARCH TABLE：使用索引查找，是理想状态。
- USING INDEX COVERING：覆盖索引，所需数据全在索引中，无需回表，性能最佳。
- USE TEMP B-TREE：使用了临时 B 树进行排序或分组，可能暗示需要优化排序字段。
4. 调整索引：如果发现 SCAN TABLE 且 WHERE 条件字段无索引，尝试创建索引。例如：CREATE INDEX idx_orders_user_id ON orders(user_id);
怎么验证是否生效
创建索引后，再次运行相同的 EXPLAIN QUERY PLAN 命令。对比前后的输出变化：
如果之前的输出包含 SCAN TABLE，而新的输出变为 SEARCH TABLE USING INDEX idx_orders_user_id，说明索引已生效。如果输出仍为 SCAN TABLE，检查是否因函数包裹字段或类型不匹配导致索引失效。此外，可以在应用层观察该接口的响应时间是否有改善，但需注意排除缓存干扰。
常见坑
1. EXPLAIN 与 EXPLAIN QUERY PLAN 的区别：单独使用 EXPLAIN 命令可能会返回虚拟机操作码（opcodes），信息过于底层且晦涩；优化查询时请明确使用 EXPLAIN QUERY PLAN 获取高层执行计划。
2. 不要混淆 MySQL 输出格式：SQLite 的执行计划输出格式与 MySQL 不同，不要期待看到 type、rows 等列，SQLite 通常返回文本描述行。
3. 索引并非越多越好：虽然索引能加快查询，但会降低写入速度并占用存储空间。每次添加索引前，确认该查询确实是高频慢查询。
4. 函数导致索引失效：如果在 WHERE 条件中对字段使用了函数（如 LEFT(email, 5)），索引可能无法被使用，导致全表扫描。
参考来源
- SQLite 百万查询优化指南：从 EXPLAIN 到索引设计，让你的查询速度飞起来
- SQLite 数据库中 [分析查询计划] 的使用
- SQLite Explain
- SQLite 慢查询:5 个监控技巧，速度提升 10 倍的秘密!