MySQL索引失效主因是最左前缀原则被破坏范围查询或跳过中间列会导致右侧列无法使用索引ORDER BY需满足最左连续列且排序方向一致索引过多拖慢写入应评估选择性与实际使用率EXPLAIN中key_len和Extra比type更能反映索引使用情况。WHERE 条件里用不到索引检查最左前缀是否被破坏MySQL 的 B 树索引生效前提是查询能从索引最左侧列开始连续匹配。一旦中间某列用了范围查询、、BETWEEN、LIKE 前缀不固定右侧所有列就无法走索引了。比如有联合索引 INDEX (a, b, c)WHERE a 1 AND b 2 AND c 3 → 全部命中WHERE a 1 AND b 2 AND c 3 → 只用到 a 和 bc 被跳过WHERE a 1 AND c 3 → 只用到 ac 完全失效b 缺失导致断层常见坑把高频过滤字段放在联合索引右边或者在中间列加了函数如 WHERE YEAR(create_time) 2024直接让整条索引失效。ORDER BY 不走索引确认排序方向和覆盖字段MySQL 要用索引做排序必须满足两个条件排序字段是索引的最左连续列且所有排序方向一致全 ASC 或全 DESC。8.0 支持混合方向但老版本不行。例如索引 INDEX (user_id, created_at)ORDER BY user_id, created_at → 可走索引排序ORDER BY user_id DESC, created_at ASC → 5.7 及以前会触发 filesortORDER BY created_at → 即使有索引也用不上因为没包含最左列 user_id额外注意如果 SELECT * 且索引不是覆盖索引MySQL 可能宁愿全表扫描 filesort也不走索引再回表——这时要权衡是否加 INCLUDE 字段或改写查询。索引太多反而拖慢写入评估更新频率和选择性每多一个索引INSERT/UPDATE/DELETE 就得多维护一份 B 树。尤其对高写入表如日志、消息队列索引数量应严格控制。 AI Code Reviewer AI自动审核代码