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 = 'a@b.com';
如果这时
key仍是
NULL，重点排查：
NULL允许？若允许，且查询条件是
WHERE email = 'x'，但该列 NULL 值占比极高，优化器可能直接弃用索引 是否在
LIKE '%abc'？这种前导通配符必然无法使用 B+Tree 索引 检查字符集/排序规则是否一致（比如表用
utf8mb4_0900_as_cs，而连接会话用
utf8mb4_general_ci），可能导致索引失效
force index 能临时绕过但不该长期依赖
加
FORCE INDEX可以强制走某个索引，用于验证“如果走索引，性能到底如何”：
EXPLAIN SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'paid' AND created_at > '2024-01-01';
但如果
key原本是
NULL，而加了
FORCE INDEX后
rows显著下降、
Extra出现
Using index或
Using index condition，说明问题不在索引缺失，而在优化器成本估算失准。此时更应： 运行
ANALYZE TABLE orders更新统计信息 检查
innodb_stats_persistent是否开启，避免统计信息长期不更新 确认
WHERE条件的选择性——低选择性（如
status IN ('paid','shipped') 占 90% 行）会让索引失去意义
覆盖索引和联合索引顺序很关键
当
key不为
NULL，但
Extra里出现
Using where; Using index，说明走了覆盖索引；如果只有
Using where，大概率发生了回表。这时候即使
key有值，性能也可能差。 联合索引要按“查询条件（= 或 IN）→ 排序字段 → 查询返回字段”顺序组织，例如
WHERE a = ? AND b > ? ORDER BY c，理想索引是
(a, b, c)如果查询里有
SELECT *，几乎不可能覆盖，除非索引包含所有列（不现实），所以优先考虑只查必要字段 注意
ORDER BY和
GROUP BY的字段顺序必须匹配索引最左前缀，否则即便
key有值，也会多出
Using filesort或
Using temporary
实际调优时，
key是
NULL往往不是孤立现象，它常和
type: ALL、
rows过大、
Extra出现
Using where或
Using temporary一起出现。盯住这几个字段组合，比单看
key更能定位根因。
