答案是使用EXPLAIN分析执行计划，检查type、key、rows和Extra字段，排查函数操作、隐式转换、LIKE前模糊、OR连接不当、未遵循最左前缀等问题，确保索引设计合理并更新统计信息。
索引失效是MySQL性能问题的常见根源。当查询没有走预期的索引，会导致全表扫描，响应变慢，资源消耗增加。要排查索引失效，核心是理解执行计划，并结合具体SQL和表结构进行分析。
查看执行计划：使用EXPLAIN
排查的第一步是使用EXPLAIN命令查看SQL的执行计划。通过它可以看到MySQL是否使用了索引、使用了哪个索引、扫描行数等关键信息。
EXPLAIN SELECT * FROM users WHERE name = 'John';重点关注以下列：
- type：访问类型，从优到差为 system > const > eq_ref > ref > range > index > ALL。ALL表示全表扫描，通常意味着索引未被使用。
- key：实际使用的索引名称。如果为NULL，则未使用索引。
- rows：预计扫描的行数。数值越大，效率越低。
- Extra：额外信息，如“Using where”、“Using index”、“Using filesort”等。“Using index”表示覆盖索引，性能好；“Using filesort”或“Using temporary”则可能存在问题。
常见导致索引失效的情况及应对
即使建了索引，某些写法仍会导致其无法生效。以下是典型场景：
-
对字段使用函数或表达式：
例如 WHERE YEAR(create_time) = 2024，即使create_time有索引，也无法使用。应改为范围查询：
WHERE create_time >= '2024-01-01' AND create_time 2025-01-01' -
隐式类型转换：
比如字符串字段phone上有索引，但查询时写了 WHERE phone = 13812345678（数字），MySQL会做类型转换，导致索引失效。应保持类型一致：
WHERE phone = '13812345678' -
使用LIKE以通配符开头：
WHERE name LIKE '%john' 无法使用索引。若必须前模糊匹配，可考虑全文索引或反向索引。 -
OR连接条件不当：
如果OR前后字段都有独立索引，有时能走索引；但如果其中一个无索引，可能导致全表扫描。建议拆分语句或使用UNION。 -
联合索引未遵循最左前缀原则：
假设索引为 (a,b,c)，只有 WHERE b=1 和 WHERE c=1 的查询无法使用该索引。应确保查询条件包含最左侧字段。
检查索引本身是否合理
索引设计不合理也会导致“看似存在却不用”。
-
选择性差的字段不宜单独建索引：
如性别、状态等枚举值少的字段，建立索引效果有限，甚至优化器会主动放弃使用。 -
频繁更新的字段索引代价高：
每次UPDATE/INSERT/DELETE都会维护索引，可能影响写入性能。 -
确认索引已正确创建：
使用 SHOW INDEX FROM table_name 查看索引是否存在，顺序是否正确。
统计信息与缓存刷新
MySQL优化器依赖表的统计信息来决定执行计划。如果统计信息过期，可能导致错误选择。
- 运行 ANALYZE TABLE table_name; 更新统计信息。
- 检查是否因缓存导致误判，可清空查询缓存（如启用）或用 SQL_NO_CACHE 测试。
基本上就这些。关键是养成写SQL后必看EXPLAIN的习惯，结合业务逻辑判断索引使用是否合理。索引不是越多越好，精准识别问题才能有效优化查询性能。
