索引列顺序错位会导致联合索引完全失效
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 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调整列序——改顺序 = 新建索引 + 删除旧索引，线上大表务必先评估锁和空间成本。
