MySQL复合索引需严格遵循最左前缀原则，否则无法命中索引：WHERE跳过首列、OR拆分、范围查询后列失效；ORDER BY/GROUP BY不延续索引顺序会触发filesort；SELECT *导致回表；JOIN中ON条件未对齐索引最左列亦致全表扫描。
WHERE 条件没按复合索引最左前缀匹配
MySQL 的 B+ 树索引要求查询必须从复合索引的最左侧列开始连续匹配，否则跳过前面列、只用后面列就无法走索引。比如有索引 INDEX idx_user_status_city (user_id, status, city)，但写成 SELECT * FROM users WHERE status = 'active' AND city = 'beijing'，这个查询完全跳过了 user_id，MySQL 只能全表扫描。
常见误写场景包括：
- 把过滤性弱的列（如
status）放在 WHERE 开头，而漏掉高区分度的前置列（如user_id） - 用
OR拆开条件，例如WHERE user_id = 1 OR status = 'active'，导致最左前缀断裂 - 对最左列用了范围查询（
>、BETWEEN、LIKE '%xxx'），后续列即使出现在 WHERE 中也无法使用索引
ORDER BY 或 GROUP BY 跨越索引顺序断层
即使 WHERE 部分命中了最左前缀，如果 ORDER BY 或 GROUP BY 的字段顺序/组合不严格延续索引定义，MySQL 仍可能放弃使用索引做排序，转而用 filesort。
例如索引是 INDEX idx_a_b_c (a, b, c)：
-
WHERE a = 1 ORDER BY b, c✅ 可利用索引排序 -
WHERE a = 1 ORDER BY c❌c不在b之后连续，无法利用索引有序性 -
WHERE a > 1 ORDER BY b❌a是范围查询，b列值在索引中不再全局有序
执行时可通过 EXPLAIN 查看 Extra 字段是否含 Using filesort 来确认。
SELECT * 导致回表 + 覆盖索引失效
复合索引本身只存索引列数据，一旦 SELECT * 或查询了非索引列，MySQL 就得回主键索引查完整行 —— 这不是索引“失效”，而是额外 I/O 开销陡增。更隐蔽的问题是：如果本可以建覆盖索引（把常用查询字段全包含进索引），却因顺序错乱导致优化器弃用。
例如高频查询是：SELECT user_id, status, city FROM users WHERE user_id = 123 AND status = 'active'，但索引建成了 (status, user_id, city)，虽然 WHERE 能用上前两列，但 user_id 不在最左，实际可能走不到索引；正确顺序应为 (user_id, status, city)，且该索引天然支持覆盖查询。
联合查询中 ON 条件未对齐索引顺序
多表 JOIN 时，驱动表的筛选条件和被驱动表的 ON 字段若没对齐复合索引顺序，极易触发全表扫描。典型例子：两张表通过 user_id 和 order_time 关联，但被驱动表的索引是 (order_time, user_id)，而 ON 写成 ON t1.user_id = t2.user_id AND t1.order_time = t2.order_time —— MySQL 无法用 user_id 单独定位，只能遍历整个 t2 索引。
关键点在于：被驱动表的索引必须让 ON 中第一个等值条件对应索引最左列。上面例子应改索引为 (user_id, order_time)，或确保 ON 中 user_id 在前且为等值匹配。
最容易被忽略的是：索引顺序错误往往不会报错，也不影响结果正确性，只在数据量上去后突然变慢 —— 所以上线前用真实数据集跑 EXPLAIN FORMAT=TRADITIONAL 看 key 和 rows 才算真正验证。
