explain的key非空不等于索引生效，需结合type（如all/index表示未有效过滤）、rows（接近总行数说明扫描未减少）、extra（如using filesort表示排序未走索引）综合判断。
EXPLAIN 不是“看到 key 有值就等于索引命中了”——它只告诉你优化器“打算用哪个索引”，真正有没有减少扫描，得看 type、rows 和 Extra 三者组合。
怎么看 type 字段判断索引是否真起作用
type 是最直接的索引效率标尺，不是 key 非空就行。它反映的是 MySQL 实际访问数据的方式：
-
const/eq_ref：极好，基本等于精准定位，比如主键或唯一索引等值查询 -
ref：常见于非唯一索引等值匹配（如WHERE status = 1），算有效走索引 -
range：范围查询（BETWEEN、IN、>），也算走索引，但扫描行数可能变多 -
index：全索引扫描，MySQL 在二级索引上逐行遍历，没用索引做过滤，只是避免回表读主键——如果rows接近表总行数，说明和全表扫差不多 -
ALL：全表扫描，索引彻底失效，哪怕key显示了索引名也白搭
典型误判：联合索引 (a,b,c)，写 WHERE a = 1 AND c = 3，type 很可能是 ref 或 range，但 c 条件实际没参与索引过滤，key_len 可能只有前两列的长度。
key_len 和 rows 联合验证索引使用深度
key_len 告诉你用了联合索引的前几列，rows 告诉你这个“用”到底省了多少事：
- 索引
idx_user_status_created是(user_id, status, created_at)，其中user_id是 BIGINT（8 字节），status是 TINYINT NOT NULL（1 字节），created_at是 DATETIME（5 字节） -
key_len = 9→ 只用了user_id+status，created_at没参与 WHERE 过滤 -
key_len = 8→ 即使写了status = 1，也没进索引查找，可能因为status允许 NULL、或者条件里用了 OR、或者该字段在索引中不是 NOT NULL 定义 -
rows如果接近表总行数（比如表有 100 万行，rows = 982341），那基本等于没过滤，别被key的名字骗了
注意：rows 是估算值，统计信息过期（比如刚批量导入完没跑 ANALYZE TABLE）会让它严重失真。不能单靠它下结论。
Extra 字段暴露隐藏代价
Extra 里藏着索引没覆盖全需求的线索，即使 type 看着还行，也可能暗藏性能坑：
-
Using index：好事，表示走了覆盖索引，不用回主键查数据 -
Using where：中性，说明索引扫描后还要在引擎层再过滤一次（比如索引只包含部分 WHERE 条件） -
Using filesort：危险信号，ORDER BY 字段没被索引覆盖，MySQL 被迫额外排序；即使type = ref，性能也可能断崖下跌 -
Using temporary：更危险，GROUP BY 或 DISTINCT 触发临时表，通常意味着索引设计不匹配查询模式 -
Using index condition：ICP（索引条件下推），说明 WHERE 中部分条件下推到存储引擎层执行，是优化行为，不是问题
例如 WHERE user_id = 100 AND status = 1 ORDER BY created_at DESC，如果没建 (user_id, status, created_at) 这样的联合索引，Extra 几乎必出 Using filesort。
为什么 SHOW STATUS 的 Handler_read_* 更值得信
EXPLAIN 是单条语句的“模拟计划”，而 SHOW STATUS LIKE 'Handler_read%' 是真实运行后的“行为快照”，尤其适合评估线上整体索引健康度：
-
Handler_read_key：通过索引定位某一行的次数（正向指标） -
Handler_read_rnd_next：全表扫描时逐行读取的次数（负向指标，越高越糟） - 粗略命中率公式：
(Handler_read_key) / (Handler_read_key + Handler_read_rnd_next) * 100%
这个比值低于 90%，就得警觉——说明大量查询其实在做全表扫描，哪怕你翻了一百条 EXPLAIN 都没发现 type = ALL。因为有些查询可能走缓存、有些被 query cache 拦截、有些压根没进慢日志，但 Handler_read_rnd_next 会如实记录每一次磁盘行读取。
真正难的不是看懂 EXPLAIN 输出，而是把 type、key_len、rows、Extra 和 Handler_read_* 四类信号交叉印证，才能避开“看着走了索引，其实没省事”的陷阱。
