联合索引怎么建才合理

联合索引（复合索引）建得合不合理，直接决定了查询能不能“走索引”、走得好不好。下面从原则、常见场景、避坑点三个层面讲清楚。

一、最核心的原则

1️⃣ 最左前缀原则（必须理解）

联合索引 (a, b, c) 相当于建立了：

• (a)
• (a, b)
• (a, b, c)

只有从最左边开始用，才能用上索引。

✅ 能用到索引：

WHERE a = 1
WHERE a = 1 AND b = 2
WHERE a = 1 AND b = 2 AND c = 3

❌ 用不到或只能用一部分：

WHERE b = 2
WHERE b = 2 AND c = 3

二、字段顺序怎么排（非常关键）

2️⃣ 区分度高的字段放前面（一般原则）

(a区分度高, b区分度低)

比如：

• user_id（高）
• status（低）

✅ 推荐：

INDEX(user_id, status)

原因：先快速缩小数据范围。

3️⃣ 常用查询条件放前面

如果业务里 几乎总是带 user_id 查，那 user_id 必须在最左。

WHERE user_id = ? AND created_at > ?
→ INDEX(user_id, created_at)

4️⃣ 范围查询字段放最后

⚠️ 范围查询（>, <, BETWEEN, LIKE 'xx%'）会中断后续索引使用

WHERE a = 1 AND b > 10 AND c = 2
INDEX(a, b, c)

实际只用到了 (a, b)，c 用不上。

✅ 更好的方式：

INDEX(a, c, b)

三、排序和分组的索引设计

5️⃣ ORDER BY 也要符合索引顺序

WHERE a = 1 ORDER BY b
INDEX(a, b)

✅ 能避免 filesort

❌ 错误示例：

ORDER BY b, a
INDEX(a, b)

6️⃣ GROUP BY 同理

GROUP BY a, b
INDEX(a, b)

四、常见组合场景示例

✅ 用户订单表

user_id, status, created_at

查询：

WHERE user_id = ? AND status = ? ORDER BY created_at

✅ 索引：

INDEX(user_id, status, created_at)

✅ 日志表

app_id, level, created_at

查询：

WHERE app_id = ? AND created_at BETWEEN ? AND ?

✅ 索引：

INDEX(app_id, created_at)

五、常见坑（非常重要）

❌ 在索引列上使用函数

WHERE DATE(created_at) = '2024-01-01'

→ 索引失效

✅ 改写为：

WHERE created_at >= '2024-01-01'
  AND created_at < '2024-01-02'

❌ 隐式类型转换

WHERE user_id = '123'  -- user_id 是 int

→ 可能不走索引

❌ 索引字段太多

• 一般 2~3 个字段 最合理
• 最多不超过 4~5 个（写性能、维护成本）

六、一个实用建索引思路（记住这个）

高频 WHERE → 高区分度 → 等值 → 范围 → ORDER BY

如果你愿意，可以把：

• 表结构
• 常用 SQL

发给我，我可以直接帮你设计最优联合索引。