联合索引失效源于违反最左前缀原则：跳过前置列（如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 > '2025-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 DESC
• ORDER 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 调整列序——改顺序 = 新建索引 + 删除旧索引，线上大表务必先评估锁和空间成本。