使用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 的使用和常见失效模式，能快速定位并修复索引问题。
