联合索引失效源于违反最左前缀原则：跳过前置列（如INDEX(city,age,status)中WHERE age=25）导致索引无法使用；仅当WHERE条件从左连续匹配时才生效，且ORDER BY/GROUP BY顺序须严格一致；高频高区分度列应置最左，调整顺序需重建索引。
索引列顺序错位会导致联合索引完全失效
MySQL 的 B+ 树索引是按定义顺序逐列比较的，WHERE 条件中如果跳过前置列（即“断层”），后续列无法利用索引。比如建了 INDEX idx_user (city, age, status)，但查询写成 WHERE age = 25 AND status = 'active'，则整个索引基本不生效——EXPLAIN 显示 key 为 NULL 或仅用到 0 列。
常见错误现象：
-
type字段显示ALL（全表扫描） -
possible_keys列出索引，但key为NULL -
rows值接近表总行数
哪些 WHERE 条件能走对顺序的联合索引
只有满足“最左前缀原则”的条件才能触发索引下推（ICP）和范围截断。以 INDEX idx_log (app_id, event_type, created_at) 为例：
- ✅
WHERE app_id = 100→ 用到第 1 列 - ✅
WHERE app_id = 100 AND event_type IN ('click', 'submit')→ 用到前 2 列 - ✅
WHERE app_id = 100 AND event_type = 'click' AND created_at > '2024-01-01'→ 全部 3 列都参与（注意：范围查询列之后的列只用于过滤，不用于查找） - ❌
WHERE event_type = 'click'→ 跳过app_id，索引失效 - ⚠️
WHERE app_id > 100 AND event_type = 'click'→event_type不再可用于索引查找（因app_id是范围，event_type只能做 ICP 过滤）
ORDER BY 和 GROUP BY 也受索引顺序严格约束
即使 WHERE 条件匹配最左前缀，若 ORDER BY 列顺序或方向与索引不一致，仍可能触发 Using filesort。例如：
CREATE INDEX idx_order (user_id, score DESC, updated_at ASC);
以下语句会避免排序：
ORDER BY user_id, score DESCORDER BY user_id, score DESC, updated_at ASC
但这些会触发 filesort：
-
ORDER BY user_id, score ASC（方向不一致） -
ORDER BY score DESC, updated_at ASC（跳过user_id） -
ORDER BY user_id DESC, score DESC（首列方向不一致，整索引无法复用）
高频等值查询列应放在联合索引最左侧
索引顺序不是随意排列的，要按区分度 + 查询频率综合权衡。例如用户表有 status（只有 'active'/'inactive'）、region（50+ 值）、created_at（高基数时间戳）：
- ❌
INDEX (status, region, created_at)→status区分度太低，前导列筛选效果差，实际扫描行数多 - ✅
INDEX (region, status, created_at)→ 先按地理区域缩小范围，再筛状态，效率更稳
注意：MySQL 8.0+ 支持降序索引，但老版本中 DESC 在联合索引里实际被忽略（全部当 ASC 存），所以排序方向必须显式匹配索引定义。
真正容易被忽略的是：索引顺序一旦建错，除非 DROP 重建，否则无法通过 ALTER 调整列序——改顺序 = 新建索引 + 删除旧索引，线上大表务必先评估锁和空间成本。
