联合索引能替代多个单列索引，因mysql b+树一次仅能有效使用一个索引，而联合索引index(a,b,c)可按最左前缀原则支持a、a+b、a+b+c等查询，避免回表；但需合理设计字段顺序、避免冗余、兼顾查询模式与区分度。
联合索引为什么能替代多个单列索引
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 = ?的独立查询，结果导致这类查询全表扫描
真正难的不是建索引，而是看清每个字段在业务查询中的角色——它是不是总是和谁一起出现？有没有被单独查过？值分布是否足够均匀？这些细节比语法规则更容易被忽略。
