第4章 索引设计原则与最佳实践
做索引设计这些年，我最大的感悟就是——索引不是万能药，但用好了确实能救命。记得有一次，线上一个查询慢得用户直接投诉，我过去一看，全表扫描，数据量已经涨到百万级了。加了个合适的复合索引，查询从2秒降到了20毫秒。嗯，这就是索引的魅力。
不过话说回来，索引也不是越多越好。我见过不少团队，一遇到慢查询就加索引，结果索引比数据还多，写入性能反而崩了。所以这一章，我想跟你聊聊索引设计到底该怎么搞。
4.1 索引的本质：空间换时间的艺术
说白了，索引就像一本书的目录。没有目录你也能找到内容，但得一页页翻。有了目录，直接定位到页数，快得多。Room底层用的是SQLite，它的索引实现是基于B+树的。
B+树的结构有个特点：数据只存在叶子节点，非叶子节点只存索引键。这样树的高度很低，查询时最多3-4次I/O就能找到数据。我个人习惯把B+树想象成一个"多层级的目录"，每一层都在缩小查找范围。
核心价值：索引用额外的存储空间换取查询时的I/O次数减少。空间开销通常在数据量的20%-50%之间，但查询性能可能提升几个数量级。
4.2 四大核心设计原则
我总结下来，索引设计就四个原则。你记牢了，能避开90%的坑。
- 原则一：高区分度列优先 —— 区分度越高，索引的过滤效果越好。性别字段区分度只有2，不适合做索引前列。用户ID、邮箱这类字段，才是好选择。
- 原则二：最左前缀法则 —— 这是复合索引的灵魂。查询条件必须从索引的最左列开始匹配，跳过了左列，索引就废了。举个例子，索引(A, B, C)，能用到A、A+B、A+B+C，但B+C就用不上。
- 原则三：覆盖索引优先 —— 如果查询的列全部在索引里，SQLite就不需要回表查了，这叫"覆盖索引"。性能提升非常明显。我一般在高频查询中会刻意设计覆盖索引。
- 原则四：避免冗余索引 —— 索引不是越多越好。索引(A)和索引(A, B)就是冗余的，前者可以被后者覆盖。冗余索引浪费空间，还拖慢写入速度。
注意：索引每多一个，写入时的维护成本就多一份。插入一条数据，所有索引都得更新。写多读少的场景，索引一定要精打细算。
4.3 复合索引的列顺序：等值优先，范围靠后
复合索引的列顺序怎么定？这是我在项目中被问得最多的问题。规则其实就一句话：等值条件的列放前面，范围条件的列放后面。
为什么会这样？你想，等值条件能精确匹配到某一行或某一小段，过滤效率极高。而范围条件（比如 >、BETWEEN、LIKE）匹配的是一个区间，放在前面会让后续的列无法精确匹配。所以等值先行，范围靠后，这是铁律。
举个例子，假设有个订单表，你经常这么查：
SELECT * FROM orders
WHERE user_id = 1001
AND status = 'PAID'
AND create_time > '2024-01-01';索引应该这么建：(user_id, status, create_time)。前两列是等值，放前面；create_time是范围，放最后。
个人习惯：我在设计复合索引时，会把所有等值条件列列出来，按区分度从高到低排，再把范围条件列放到最后。这样既遵循了等值优先，又兼顾了区分度。
4.4 常见索引陷阱
这些坑我几乎都踩过，拿出来给你提个醒。
陷阱一：在索引列上使用函数
我曾经在代码里写了 WHERE DATE(create_time) = '2024-01-01'，觉得没毛病。结果一查，全表扫描。为什么？因为函数把索引列的值改了，SQLite没法用索引。正确的写法是 WHERE create_time >= '2024-01-01' AND create_time < '2024-01-02'。
陷阱二：隐式类型转换
如果索引列是整数类型，查询条件写 WHERE user_id = '1001'，SQLite会尝试把字符串转成整数，索引还是能用的。但反过来，如果索引列是字符串，条件写 WHERE name = 123，类型转换会导致索引失效。这个我踩过一次，排查了半天。
陷阱三：索引过多导致写入慢
有个项目，线上订单表有8个索引，写入时经常超时。我一看，很多索引根本没用上。删掉4个冗余索引后，写入延迟降了60%。记住，索引不是勋章，不是越多越好。
4.5 用 EXPLAIN QUERY PLAN 验证索引
索引到底有没有生效？别靠猜，用 EXPLAIN QUERY PLAN 看一眼就清楚了。这是Room调试中我最常用的工具。
EXPLAIN QUERY PLAN
SELECT * FROM orders
WHERE user_id = 1001
AND status = 'PAID'
AND create_time > '2024-01-01';输出结果中，如果看到 USING INDEX 或者 USING COVERING INDEX，说明索引生效了。如果是 SCAN TABLE，那就是全表扫描，索引没起作用。
小技巧：我会把所有核心查询的EXPLAIN结果记录下来，放到一个文档里。每次修改索引后，对比一下执行计划有没有变差。这样能及时发现回归问题。
4.6 索引设计决策一览表
下面这个表是我在实际项目中总结出来的，遇到对应场景可以直接参考。
| 查询场景 | 推荐索引策略 | 注意事项 |
|---|---|---|
| 单列等值查询 | 单列索引即可 | 区分度高的列优先 |
| 多列等值查询 | 复合索引，等值列全包含 | 区分度高的列放前面 |
| 等值+范围查询 | 复合索引，等值列在前，范围列在后 | 范围条件只能匹配到最后一个范围列 |
| 排序查询（ORDER BY） | 包含排序列的索引，顺序一致 | 升序降序要匹配，否则无法利用索引 |
| 高频查询，返回列少 | 覆盖索引，包含所有查询列 | 避免回表，性能最优 |
| 模糊查询（LIKE） | 前缀匹配可以用索引，后缀匹配不行 | LIKE 'abc%' 能用索引，LIKE '%abc' 不能 |
4.7 实战避坑指南
最后分享几个我亲身经历的教训，希望能帮你少走弯路。
案例一：复合索引顺序搞反了
我曾经设计了一个索引 (create_time, user_id)，觉得时间范围查询用得多就放前面了。结果发现 WHERE user_id = ? 的查询根本用不上这个索引。后来改成 (user_id, create_time)，两个查询都受益了。这就是最左前缀法则的教训。
案例二：忽略覆盖索引
有个列表页查询，每次只查 id 和 name 两列，但索引只建在 id 上。每次查询都得回表，慢得不行。我把索引改成 (id, name) 后，查询直接在索引里完成了，耗时降了80%。这就是覆盖索引的威力。
案例三：线上加索引要谨慎
在线上库直接 CREATE INDEX 会导致锁表，Room 里如果数据量大，可能引发 ANR。我现在都是先在测试环境用 EXPLAIN QUERY PLAN 验证索引效果，再用 @Index 注解在 Room 迁移脚本中异步创建。安全第一。
嗯，索引设计这个东西，说难不难，说简单也不简单。关键是要理解它的底层原理，然后结合实际查询模式去设计。记住今天讲的这几个原则和坑，你在Room里做索引设计应该能少走不少弯路。