key 为 NULL 表示优化器未选择索引而执行全表扫描，主因是成本估算认为索引访问不划算，常见于条件未命中最左前缀、隐式类型转换、函数操作、统计信息过期或高比例匹配等场景。
key 为 NULL 表示没走索引
MySQL 执行计划（EXPLAIN 输出）中 key 列为 NULL，说明优化器最终没有选择任何索引去访问该表，而是走了全表扫描（type 通常是 ALL）。这不是“索引不可用”，而是“优化器判断用索引不划算”——可能因为：
- 查询条件没命中索引最左前缀（比如对复合索引
(a,b,c)只写了WHERE b = ?） - 字段存在隐式类型转换（如
WHERE user_id = '123'，而user_id是INT） - 索引列上用了函数或表达式（如
WHERE UPPER(name) = 'ABC'） - 统计信息过期，优化器误判行数，认为全表扫描比索引回表更快
- 查询返回大量数据（例如
SELECT *+ 高比例匹配），优化器放弃索引+回表的开销
怎么确认是不是索引本身失效了
别急着删重建索引，先验证索引是否真的“能用”。执行 SHOW INDEX FROM table_name 确认索引存在且状态正常；再用 EXPLAIN 检查带索引字段的**最简等值查询**：
EXPLAIN SELECT * FROM users WHERE email = '[email protected]';
如果这时 key 仍是 NULL，重点排查：
-
email字段是否为NULL允许？若允许，且查询条件是WHERE email = 'x'，但该列 NULL 值占比极高，优化器可能直接弃用索引 - 是否在
email上建的是普通索引，但查询用了LIKE '%abc'？这种前导通配符必然无法使用 B+Tree 索引 - 检查字符集/排序规则是否一致（比如表用
utf8mb4_0900_as_cs，而连接会话用utf8mb4_general_ci），可能导致索引失效
force index 能临时绕过但不该长期依赖
加 FORCE INDEX 可以强制走某个索引，用于验证“如果走索引，性能到底如何”：
