使用EXPLAIN分析执行计划,通过type、key、rows和Extra字段判断索引是否失效;常见失效场景包括函数操作、隐式转换、不等于条件、左模糊查询、违背最左前缀原则及OR连接无索引字段。

在MySQL中,索引失效会导致查询性能大幅下降。要分析索引是否失效,关键在于理解执行计划(EXPLAIN)的输出,并结合常见的索引使用规则进行判断。以下是实用的分析方法和常见失效场景。
查看执行计划:使用EXPLAIN分析SQL
在SQL语句前加上EXPLAIN,可以查看MySQL如何执行这条查询,重点关注以下几个字段:
-
type:访问类型,从优到差为 system → const → eq_ref → ref → range → index → ALL。ALL 表示全表扫描,很可能索引失效。
-
key:实际使用的索引。如果为 NULL,说明未使用索引。
-
possible_keys:可能用到的索引。若此字段有值但 key 为 NULL,说明索引未被选中。
-
rows:预计扫描的行数。数值越大,效率越低。
-
Extra:额外信息,出现 Using filesort 或 Using temporary 通常意味着性能问题。
示例:
EXPLAIN SELECT * FROM users WHERE name = 'John';
登录后复制
如果 key 为 NULL 且 type 是 ALL,说明没有走索引。
常见索引失效场景及原因
即使建了索引,以下情况仍可能导致索引无法使用:
-
对索引列进行表达式或函数操作:
如 WHERE YEAR(create_time) = 2023,MySQL无法直接使用create_time的索引。应改为范围查询:WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。
-
隐式类型转换:
比如索引列是字符串类型,查询时用数字:WHERE user_id = 123(user_id为VARCHAR)。这会触发类型转换,导致索引失效。
-
使用不等于(!= 或 )、NOT IN、NOT EXISTS:
这些条件通常无法有效利用B+树索引,容易引起全表扫描。
-
左模糊匹配:
LIKE '%abc' 无法使用索引;而 LIKE 'abc%' 可以。因为B+树是按前缀排序的。
-
联合索引未遵循最左前缀原则:
例如联合索引 (a, b, c),只有 WHERE a=1 AND b=2 才能使用索引;若只查 b 或 c,则索引无效。
-
OR连接条件中部分字段无索引:
WHERE a=1 OR b=2,如果b没有索引,可能导致整个条件不走索引。
优化建议与排查步骤
为了确保索引生效,可按以下步骤检查和优化:
- 对慢查询日志中的SQL使用 EXPLAIN 分析执行路径。
- 确认查询条件中的字段类型与索引列一致,避免隐式转换。
- 合理设计联合索引,确保常用查询满足最左前缀匹配。
- 避免在索引列上做计算、函数、类型转换等操作。
- 使用覆盖索引减少回表,即查询字段都在索引中。
- 定期分析表统计信息(ANALYZE TABLE),帮助优化器做出更好决策。
基本上就这些。掌握 EXPLAIN 的使用和常见失效模式,能快速定位并修复索引问题。
以上就是mysql如何分析索引失效_mysql索引失效分析方法的详细内容,更多请关注php中文网其它相关文章!