如何查看MySQL索引是否生效_通过EXPLAIN执行计划查看key字段-mysql教程-PHP中文网

key非空不等于索引生效，需结合type、rows、extra判断：type为all/index、rows接近总行数、extra含filesort/temporary均表明实际未有效利用索引。

如何查看mysql索引是否生效_通过explain执行计划查看key字段

EXPLAIN 的 key 字段非空，不等于索引生效了——它只表示优化器“打算用”，不是“真用了”。

为什么 `key` 有值却还是慢？

这是最常被误读的点。key 显示的是 MySQL 优化器在解析阶段选出的索引，但执行时是否真正靠它过滤数据，得看其他字段：type、rows、Extra 才是关键证据。

type 是 ALL 或 index：说明实际做了全表扫描或全索引遍历，key 再亮也没用
rows 接近表总行数：哪怕 key 非空，也大概率只是用来排序或覆盖，没减少 I/O
Extra 出现 Using filesort 或 Using temporary：ORDER BY / GROUP BY 没命中索引顺序，被迫回表或建临时结构

`type` 值才是索引效率的硬指标

它直接反映扫描范围和匹配精度，从高到低大致为：const ≈ eq_ref > ref > range > index > ALL。重点关注是否掉到 range 以下：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

ref 变成 range：检查 WHERE 里有没有对索引列用函数，比如 WHERE YEAR(create_time) = 2023 —— 索引失效
联合索引 (a,b,c)，条件写成 WHERE a = 1 AND c = 3：b 被跳过，c 部分无法利用
type 是 index 且 rows 很大：说明在遍历整个二级索引，考虑加覆盖索引或精简 SELECT 字段

当 `key` 为空时，先别急着删索引

key 为 NULL 表示这次查询完全没走索引，但原因可能不止“没建”：

possible_keys 有值而 key 为空：说明索引存在，但优化器认为它不如全表扫描快（比如小表、统计信息不准、数据倾斜）
查的是 SELECT *，但索引不覆盖所有字段：优化器可能放弃走索引，改用主键回表，成本更高
WHERE 条件含 OR，且其中一侧字段无索引：整个条件退化为全表扫描，哪怕另一侧有索引
LIKE 以 % 开头：WHERE name LIKE '%abc' —— B+Tree 无法左前缀匹配

比 EXPLAIN 更真实的索引使用证据

EXPLAIN 是单次查询的“快照”，想确认一个索引是不是长期闲置，得看运行时真实调用记录：

performance_schema.table_io_waits_summary_by_index_usage 表里，COUNT_FETCH 为 0 且持续多天 → 这个索引基本是“僵尸索引”
查之前先确认 performance_schema 已启用：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema';
过滤系统库很重要：WHERE OBJECT_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema')，否则结果被干扰
慢查询日志里的 Rows_examined 值，比 EXPLAIN 的 rows 更接近真实开销，尤其适合抓“假装走索引实则扫全表”的 case

真正难的不是看懂 key，而是把 key、type、rows、Extra 四个字段串起来读——它们之间互相印证，漏掉任何一个，都可能把“索引未生效”错判成“索引已生效”。