explain的key和type是最直接索引命中信号：key为null说明完全未走索引；type为const/eq_ref/ref/range表示有效命中，all或index则基本失效；需结合key_len、rows、extra等字段综合判断实际使用质量。
EXPLAIN 的 key 和 type 是最直接的索引命中信号
如果 key 字段为 NULL，说明这条查询完全没走索引；哪怕 possible_keys 有值，只要 key 是空，就等于“有索引但没用上”。type 字段则告诉你用了哪种访问方式：const、eq_ref、ref、range 都算有效命中；而 ALL（全表扫描）或 index（全索引扫描）基本等于没命中好索引。
注意：复合索引只匹配最左前缀。比如索引是 (a,b,c)，WHERE 条件里只有 b = ? 或 c = ?，key 依然会是 NULL —— 这不是 MySQL 拒绝用索引，而是它根本没法跳过 a 直接定位。
Extra 里的 Using index 和 Using index condition 区别很大
Using index 表示覆盖索引生效：查询所需所有字段都在索引里，连主键回表都省了，性能最优。Using index condition 是索引条件下推（ICP），意思是 WHERE 中部分条件由存储引擎在索引层过滤，减少回表行数，也属有效利用，但不如前者彻底。
一旦看到 Using filesort 或 Using temporary，哪怕 key 不为空，也说明排序或分组没走索引，可能需要调整 ORDER BY 字段顺序，或补上包含排序字段的复合索引。
- 如果
Extra是Using where，但key为NULL，说明 WHERE 条件纯靠扫描后过滤，没走索引 -
Using index只对 SELECT 列全落在索引内才触发，SELECT * 基本不可能出现它
rows 和 key_len 揭露索引使用质量
rows 是优化器预估扫描行数，数值越小越好。但如果实际执行慢，而 rows 却很小，可能是统计信息过期，需运行 ANALYZE TABLE 更新。
key_len 显示实际用到的索引字节数。例如索引 (status, created_at)，其中 status 是 TINYINT（1 字节），created_at 是 DATETIME（8 字节）。若 key_len = 1，说明只用到了 status；若 = 9，说明两个字段都被用上了。值偏小往往意味着索引没被充分利用。
- NULLABLE 字段会让
key_len+1（标记是否为 NULL） - 变长字段如 VARCHAR(255) 实际只存 10 个字符时，
key_len也会反映真实长度，不是固定 255
别只看单条 EXPLAIN，要结合 Handler_read% 看全局
单条语句 EXPLAIN 结果再漂亮，也不能代表线上真实负载下索引是否健康。执行 SHOW GLOBAL STATUS LIKE 'Handler_read%'，重点关注：
Handler_read_key 越高越好，代表通过索引取数据的次数多；Handler_read_rnd_next 过高（尤其远超 Handler_read_key）说明大量随机 I/O，通常是排序/分页没走索引、或索引选择性太差导致回表成本飙升。
这个指标是累计值，建议在业务低峰采集基线，再对比高峰时段变化。突然暴涨的 Handler_read_rnd_next 往往对应某类未优化的分页查询（如 LIMIT 10000, 20）或缺失排序字段索引。
真正难判断的不是“有没有用索引”，而是“用得够不够聪明”——比如走了索引却扫了 80% 的索引树，和全表扫描耗时可能相差无几。这时候得回到 rows、filtered、字段选择性，甚至查 information_schema.STATISTICS 看索引基数，才能下结论。
