面对千万级数据的 SQLite 表，解决查询慢问题的首要任务是消除全表扫描，这通常需要通过建立合适的索引并调整查询语句来实现，同时必须通过执行计划确认优化效果。

命令速用版

以下是排查和优化过程中最常用的几条命令，可直接在 SQLite 客户端执行：

-- 查看查询执行计划，确认是否全表扫描
EXPLAIN QUERY PLAN SELECT * FROM table_name WHERE column = value;

-- 创建索引
CREATE INDEX idx_column ON table_name(column);

-- 开启 WAL 模式提升并发写入性能
PRAGMA journal_mode=WAL;

为什么会这样

SQLite 默认使用 B 树结构存储数据和索引。如果没有索引，数据库引擎在查询时不得不逐行遍历整张表，这就是全表扫描（SCAN TABLE）。当数据量达到千万级时，逐行读取的 IO 开销会急剧增加，导致界面卡顿或操作无响应。

索引之于数据库，就像目录之于书籍。有了合适的索引，引擎能像查字典一样快速定位到目标数据行。但索引并非万能，如果查询语句写法不当，优化器可能无法使用索引，从而退化为全表扫描。

分步处理

1. 分析慢查询语句

找出执行时间长的 SQL 语句，通常是涉及大量数据筛选的 SELECT 操作。使用 EXPLAIN QUERY PLAN 命令查看其执行计划。如果输出中包含 SCAN TABLE，说明发生了全表扫描。

2. 建立针对性索引

针对 WHERE 子句和 ORDER BY 子句中涉及的列创建索引。注意不要过度创建索引，因为索引会增加插入和更新操作的开销。对于经常用于查询条件的列，可以使用 CREATE INDEX 语句。

3. 优化查询写法

检查 SQL 语句是否存在导致索引失效的写法。例如，避免在 WHERE 子句中对字段进行函数操作或算术运算，避免使用 leading wildcard 的 LIKE 查询（如 '%abc'）。对于连续数值，优先使用 BETWEEN 而不是 IN。

4. 启用 WAL 模式

对于写入频繁的场景，可以通过 PRAGMA journal_mode=WAL 启用预写日志模式，这有助于提高并发读写性能，减少锁竞争。

怎么验证是否生效

优化后，再次执行 EXPLAIN QUERY PLAN 命令。如果输出中不再出现 SCAN TABLE，而是显示 SEARCH TABLE 或 USING INDEX，说明索引已被利用。此外，可以对比优化前后的查询响应时间，但需注意测试环境的一致性。

公开资料中没有看到可靠的量化数据表明具体的性能提升百分比，因为实际效果取决于硬件、数据分布和查询复杂度，但消除全表扫描通常能带来数量级的效率改善。

常见坑

1. 模糊查询滥用

使用 LIKE '%keyword%' 会导致索引失效，引发全表扫描。如果必须做全文搜索，建议考虑 SQLite 的全文搜索虚拟表（FTS5）。

2. 字段运算与函数

在 WHERE 子句的等号左边对字段进行运算（如 num/2=100）或函数操作（如 substring(name,1,3)），会导致引擎放弃使用索引。应改为对常数进行运算或使用范围查询。

3. 空值判断与 OR 连接

尽量避免在 WHERE 子句中对字段进行 NULL 值判断或使用 OR 连接条件，这可能导致索引失效。可以通过设置默认值替代 NULL，或使用 UNION ALL 替代 OR。

4. 索引过多

虽然索引能加速查询，但过多的索引会降低写入性能。需要权衡查询和更新频率，避免创建不必要的索引。

参考来源

• SQLite 索引优化全指南：如何避免全表扫描提升查询速度
• sqlite 处理百万级数据 百万级 sql 查询
• 鸿蒙数据库性能调优笔记：用 RdbPredicates 避开全表扫描，让你的查询快起来-CSDN 博客
• Sqlite 数据库的性能如何优化？
• SQLite 查询大型字符串时优化查询的最佳方式
• SQLite 优化实践：数据库设计、索引、查询和分库分表策略
• SQLite 数据库中查询性能优化及索引创建的原则总结