EXPLAIN看不出索引失效是因为它只显示优化器预估的执行计划，不反映实际执行时的隐式类型转换或统计偏差；例如VARCHAR字段用数字查询导致隐式转换，虽type仍为ref但rows激增，即为失效信号。
为什么 EXPLAIN 看不出索引失效？
因为 EXPLAIN 只显示优化器“打算怎么走”，不反映实际执行时的隐式类型转换或统计信息偏差。比如字段是 VARCHAR，但查询里写了 WHERE id = 123（没加引号），MySQL 会隐式转成数字，导致索引失效——EXPLAIN 的 type 可能还是 ref，但 rows 突然暴涨，这就是信号。
实操建议：
- 别只盯
key列是否为NULL，重点看rows和Extra：出现Using filesort或Using temporary时，大概率已有路径退化 - 用
SHOW INDEX FROM table_name核对索引列顺序，联合索引(a,b,c)对WHERE b = ?是无效的 - 在慢查询日志里抓出真实执行时间 > 1s 的语句，再跑一遍
EXPLAIN FORMAT=JSON，看used_columns和range_analysis里的拒绝原因
LIKE '%abc' 一定走不了索引？
不一定，但绝大多数情况确实失效。B+ 树索引按字典序存储，LIKE 开头带通配符时无法定位左边界，只能全扫。例外是 MySQL 8.0+ 的倒排索引（INVERTED）或全文索引，但那是另一套机制，和普通 B+ 树无关。
常见错误现象：开发说“我加了索引，但 LIKE 还是慢”，一查发现是 LIKE '%关键词%'。
实操建议：
- 前缀匹配
LIKE 'abc%'可走索引，但注意字符集影响：utf8mb4 下一个 emoji 占 4 字节，LEFT(col, 3)可能截断半个字符，导致索引范围计算错误 - 模糊搜索需求强烈时，别硬扛，改用
MATCH ... AGAINST（全文索引）或外部方案如 Elasticsearch - 如果必须用
LIKE '%x%'且数据量小（-- @WARN: forced fullscan, data size
函数包裹字段让索引失效的真实场景
不是所有函数都必然失效，关键看是否破坏“索引列的有序性”。比如 WHERE YEAR(create_time) = 2023 失效，因为优化器无法把 YEAR() 映射回 B+ 树里的时间范围；但 WHERE create_time >= '2023-01-01' AND create_time 就能走索引。
容易被忽略的坑：
-
WHERE UPPER(name) = 'ABC'失效，但若字段本身建了函数索引（MySQL 8.0+）：CREATE INDEX idx_name_upper ON t1 ((UPPER(name)))，就能生效 -
WHERE col + 0 = 123看似没函数，其实是隐式类型转换，col是字符串时会触发全表转换，索引失效 -
ORDER BY RAND()必然放弃索引，连LIMIT都救不回来，抽样必须换思路（比如先SELECT id再应用层随机取）
复合索引最左匹配失效的典型条件
最左匹配不是“只要左边有就用”，而是“从最左列开始，连续的等值条件才能启用后续列”。比如索引是 (a, b, c)，WHERE a = 1 AND c = 3 只能用上 a，c 被跳过；但如果 WHERE a = 1 AND b > 10 AND c = 3，c 就完全用不上——因为 b 是范围查询，后面的列无法用于索引查找。
实操建议：
- 联合索引列顺序按“过滤强度”从高到低排，比如用户表中
status（3 个值）不如create_time（高区分度）适合放前面 - 避免在索引列上做计算：
WHERE a + 1 = 10比WHERE a = 9少用一层索引 - 用
SELECT COUNT(*)验证：对(a,b)索引执行SELECT COUNT(*) FROM t WHERE a=1和SELECT COUNT(*) FROM t WHERE a=1 AND b=2，观察Handler_read_next值是否明显下降
索引失效往往不是单点问题，而是统计信息过期、字符集不一致、隐式转换、查询条件写法这四者交织的结果。调的时候别只盯着 SQL，顺手查下 SHOW TABLE STATUS LIKE 't' 里的 Rows 和 Data_length 是否严重偏离实际，有时候重建统计信息比改 SQL 更快。
