SQLite的复合索引并不是简单地把多个单列索引拼在一起，而是一棵以多个列值为排序键的B树。理解这一点，是设计高效复合索引的前提。如果只是机械地为每个查询字段单独建索引，很容易遇到查询时索引未被使用的情况，最终仍然退化为全表扫描。本文从复合索引的底层结构出发，梳理最左前缀规则、列顺序选择、覆盖索引和查询计划验证等关键实践。
复合索引的底层结构与最左前缀规则
SQLite使用B树结构存储索引，复合索引的键由多个列的值拼接而成。B树在排序时，先按第一列比较，第一列相同再比较第二列，依次类推。例如索引(user_id, status, created_at)的物理顺序是：先按user_id升序排列，相同user_id内部再按status升序排列，如果status也相同，最后按created_at升序排列。这种排序方式决定了查询条件必须从索引的最左列开始匹配，也就是常说的最左前缀规则。
最左前缀规则的含义是：如果查询条件没有包含索引的第一列，那么整个复合索引都无法被用来缩小扫描范围。例如表orders上有索引(user_id, status, created_at)，查询WHERE user_id = 1024可以利用该索引快速定位到所有user_id等于1024的记录；但查询WHERE status = 'paid'则无法使用这个复合索引，因为status不是最左列。同样，查询WHERE user_id = 1024 AND created_at = '2024-01-01'只能用索引匹配user_id这一列，中间的status列缺失，导致created_at无法作为索引条件继续缩小范围。
范围条件也会影响后续列的使用。例如查询WHERE user_id = 1024 AND status >= 'paid'，索引可以定位到user_id和status的起始位置，但如果后面还有created_at条件，则无法继续通过索引精确匹配。创建复合索引和编写查询的典型示例如下：
CREATE TABLE orders (
id INTEGER PRIMARY KEY,
user_id INTEGER NOT NULL,
status TEXT NOT NULL,
created_at TEXT NOT NULL
);
CREATE INDEX idx_user_status_created
ON orders (user_id, status, created_at);
-- 能有效使用索引
SELECT * FROM orders
WHERE user_id = 1024
AND status = 'paid';
-- 无法使用索引
SELECT * FROM orders
WHERE status = 'paid';
理解最左前缀规则后，就可以避免很多无意义的索引设计。与其为每个字段单独建索引，不如根据实际查询模式把高频的等值条件组合成一个复合索引。
如何选择复合索引的列顺序与避免冗余索引
复合索引的列顺序直接影响查询效率，通常应把区分度高的列放在前面。区分度是指列中不同值的数量占记录总数的比例，区分度越高，索引过滤掉的数据就越多。例如user_id通常有大量不同值，而status可能只有几个固定状态。如果把status放在复合索引第一列，查询WHERE status = 'paid' AND user_id = 1024时，SQLite会先按status定位到一大批记录，再在其中查找user_id，扫描范围远大于将user_id放在首位的情况。
等值条件列应放在范围条件列之前。比如查询模式为WHERE user_id = ? AND created_at BETWEEN ? AND ?，最佳索引是(user_id, created_at)。如果使用(created_at, user_id)，则created_at作为范围条件会阻止后续user_id的精确匹配，索引只能用到created_at一个列。对比两种索引顺序：
-- 更优的设计：等值条件放前，范围条件放后 CREATE INDEX idx_user_created ON orders (user_id, created_at); -- 较差的设计：范围列放前，后续列无法利用 CREATE INDEX idx_created_user ON orders (created_at, user_id);
冗余索引是另一个需要警惕的问题。如果已经存在复合索引(user_id, status, created_at)，那么单列user_id索引通常是冗余的，因为最左前缀规则可以保证只使用user_id条件的查询也能利用这个复合索引。但反过来，如果业务中存在大量仅按status查询的场景，则需要单独为status建立索引，或者重新考虑复合索引的列顺序。索引会占用磁盘空间，并且每次插入、更新、删除数据时都要维护索引，冗余索引会放大写入开销。因此，在新增索引之前，应审查已有索引是否已经覆盖了新的查询模式。
利用覆盖索引与EXPLAIN QUERY PLAN验证设计
覆盖索引是指查询需要的所有列都包含在索引中，这样SQLite无需回表读取数据页，直接通过索引就能返回结果。例如查询SELECT user_id, status, created_at FROM orders WHERE user_id = 1024 AND status = 'paid'，如果复合索引(user_id, status, created_at)已经包含这三个列，就可以避免访问orders表的数据行，显著减少磁盘I/O。使用EXPLAIN QUERY PLAN可以查看执行计划，如果输出中出现USING COVERING INDEX，说明查询命中了覆盖索引。
EXPLAIN QUERY PLAN SELECT user_id, status, created_at FROM orders WHERE user_id = 1024 AND status = 'paid';
排序和分组操作同样可以从复合索引中受益。如果ORDER BY子句的列顺序与复合索引的列顺序一致，SQLite可以直接按照索引顺序返回结果，避免额外的临时B树排序。例如索引(user_id, status, created_at)能优化ORDER BY user_id, status, created_at；但如果写成ORDER BY status, created_at，由于跳过了user_id，索引无法直接用于排序，执行计划中可能出现USE TEMP B-TREE FOR ORDER BY。以下查询可以避免临时排序：
SELECT user_id, status, created_at FROM orders WHERE user_id = 1024 ORDER BY status, created_at;
设计复合索引后，不能仅仅依赖经验的判断，必须通过EXPLAIN QUERY PLAN验证是否真正生效。执行计划中如果出现SCAN orders，说明仍然是全表扫描；如果出现USE TEMP B-TREE FOR ORDER BY，说明排序没有走索引。根据这些输出调整索引列顺序或补充覆盖列，是SQLite查询优化的常规做法。实践流程可以归纳为：先梳理高频查询条件，按等值优先和选择性优先的原则创建复合索引，再用EXPLAIN QUERY PLAN逐条验证，最后删除不再被使用或冗余的索引，降低写放大和存储成本。
SQLite复合索引索引最佳实践查询优化修改时间：2026-10-03 10:57:43