【数据存储】SQLite 复合索引实测：查询字段顺序对耗时的影响

实战应用：用在哪里

玩家数据入 SQLite 后，查询模式决定索引设计：按账号查、按等级排序、按在线状态筛选——每种高频查询都需要匹配的索引。索引设计错误的典型症状：表只有几万行时一切正常，涨到百万行后某条查询从 5ms 恶化到 2 秒。本文用实测数据说明复合索引的字段顺序规则。

实测设置与三组查询

测试表 players（50 万行），字段 account、level、online、last_login。三组高频查询与对应索引：

-- 查询1：精确账号（登录路径）
SELECT * FROM players WHERE account = 'abc';
-- 查询2：在线玩家按等级排序（排行）
SELECT * FROM players WHERE online = 1 ORDER BY level DESC;
-- 查询3：等级范围 + 最近登录（运营筛选）
SELECT * FROM players WHERE level >= 80 AND last_login > 1700000000;

无索引时三组全表扫描：查询1 约 480ms、查询2 约 510ms、查询3 约 530ms（50 万行）。分别建索引后实测：查询1 建单列 account 索引 → 0.3ms；查询2 建复合索引 (online, level) → 0.8ms（顺序不能反）；查询3 建复合索引 (level, last_login) → 1.1ms。

复合索引的字段顺序规则

规则一句话：等值条件字段在前，范围/排序字段在后。查询2 的 online 是等值、level 是排序，(online, level) 顺序正确；反过来建 (level, online) 时 online 条件无法利用索引连续区间，实测退化到 300ms。解释：复合索引按第一字段排序，第一字段相同的记录再按第二字段排序——只有这个顺序才能同时满足过滤与排序。

维护建议三条

索引数量控制：每个索引都拖慢写入，写多读少的表单表索引不超过 4 个。用 EXPLAIN QUERY PLAN 验证每条查询确实走了索引（输出出现 SCAN TABLE 即全表扫描）。定期用 sqlite3_analyzer 工具看表与索引的统计信息，数据分布变化后重估索引收益。索引设计做完这三步，SQLite 在百万行级别依然能保持毫秒级查询。

索引失效的两个常见写法：条件里对字段套函数（WHERE upper(account)=）会让索引失效，改为存入时就统一大小写；隐式类型转换（字段存字符串、条件传数字）同样走全表扫描。EXPLAIN 输出里出现 SEARCH TABLE USING INDEX 才算走对。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。