联合索引为什么能替代多个单列索引
MySQL 的 B+ 树索引在执行查询时，一次只能用上一个索引（除非走
index_merge，但该策略有严格限制且性能不稳定）。当你建了
INDEX(a)、
INDEX(b)、
INDEX(c)三个单列索引，WHERE 条件是
a = ? AND b = ? AND c = ?时，优化器大概率只选其中一个索引，其余字段靠回表过滤，效率远不如一个覆盖全部条件的联合索引。
联合索引
INDEX(a, b, c)可以高效支持以下查询：
a = ?
a = ? AND b = ?
a = ? AND b = ? AND c = ?
a = ? AND c = ?（
b是中间缺失项，
c无法命中，但
a仍可用）
最左前缀原则不是“必须连续”，而是“中断即失效”
所谓“最左前缀”，是指从联合索引最左侧字段开始，连续匹配若干字段。一旦跳过某个字段（未出现在 WHERE 中），其右侧字段就不再参与索引查找。
例如索引为
INDEX(user_id, status, created_at)：
WHERE user_id = 123 AND status = 'active'→ ✅ 用到前两列
WHERE user_id = 123 AND created_at > '2024-01-01'→ ⚠️ 只用到
user_id，
created_at因
status缺失而无法走索引
WHERE status = 'active' AND created_at > '2024-01-01'→ ❌ 完全用不上该索引（
user_id没出现）
注意：
ORDER BY和
GROUP BY同样受最左前缀约束；如果需要排序加速，要把排序字段尽量放在联合索引靠后但连续的位置。
如何判断是否该用联合索引代替单列索引
核心看查询模式是否稳定、高频，以及字段组合是否经常一起出现。不要为了“看起来更优雅”而盲目合并。
先用EXPLAIN看现有单列索引的实际使用情况：如果
key列总是一个索引，
rows却很大，说明其他条件没走索引 检查慢查日志里反复出现的 WHERE 组合，比如频繁出现
WHERE tenant_id = ? AND deleted = 0 AND status IN (...)，这就是联合索引的明确信号 删掉冗余单列索引前，确认它们没被其他查询独占依赖（例如某个接口只查
status，那单独的
INDEX(status)就不能删） 联合索引字段顺序很重要：等值查询字段放前，范围查询（
>,
IN,
BETWEEN）放后，排序字段放最后（如需支持
ORDER BY created_at DESC）
联合索引的常见误操作和代价
联合索引不是银弹，加得不好反而拖慢写入、浪费空间、干扰优化器选择。
字段太多：超过 4 个字段的联合索引通常意义不大，维护成本高，且容易因长度超限被截断（尤其是含VARCHAR(255)的字段） 顺序反了：把高区分度字段（如
user_id）放后面，低区分度字段（如
is_deleted）放前面，会导致索引选择性骤降，优化器可能直接放弃使用 忽略隐式类型转换：比如
user_id是
BIGINT，但查询时传了字符串
'123'，即使有联合索引也会失效（触发隐式转换） 没清理旧索引：删掉
INDEX(a)和
INDEX(b)前，没确认是否存在
WHERE b = ?的独立查询，结果导致这类查询全表扫描
真正难的不是建索引，而是看清每个字段在业务查询中的角色——它是不是总是和谁一起出现？有没有被单独查过？值分布是否足够均匀？这些细节比语法规则更容易被忽略。
