key字段表示优化器实际使用的索引名，但需结合type、key_len、rows和Extra综合判断是否有效命中；key非NULL不等于高效，可能仅部分命中或仅用于排序/分组。
SQL执行计划里的key字段，直接告诉你优化器**实际使用了哪个索引**。它不等于“有没有建索引”，也不代表“一定高效”，而是执行时真正拿去查找数据的那个索引名。判断是否命中索引，不能只看key是否为NULL，还要结合type、key_len、rows和Extra一起看。
key非NULL ≠ 索引有效命中
即使key显示了索引名，也可能只是“部分命中”或“仅用于排序/分组”。比如：
- 查询
WHERE a = 1 ORDER BY b，有联合索引(a, b)，key会显示该索引，但若b不是范围条件，排序可能走索引，否则仍需filesort； -
WHERE a > 1 AND b = 2，联合索引(a, b)中a是范围查询，b无法用上索引下推（ICP），key_len可能只体现a的长度，b实际是回表后过滤。
看key_len确认索引用了几列
key_len反映MySQL实际使用的索引字节数。结合字段类型和是否允许NULL，能反推出用了索引的前几列：
-
VARCHAR(50)+utf8mb4→ 单字符最多4字节，加2字节长度标识 → 最大202字节； - 如果联合索引
(a INT, b VARCHAR(50), c DATETIME)，key_len = 5（INT 4字节 + NULL标志1字节），说明只用到了a； -
key_len = 207（4+202+1）→ 三列全用，且c非NULL；若c可为NULL，则再+1字节。
key为NULL但type是range或ref？小心隐式转换
有时key为NULL，但type却是range甚至ref，这往往意味着：发生了类型隐式转换，导致索引失效。典型场景：
- 字段是
VARCHAR，但查询写成WHERE col = 123（数字）→ MySQL转成WHERE CAST(col AS SIGNED) = 123，无法走索引； - 字段是
CHAR(10)带空格，而参数传入'abc'（无空格），比较时补空格，但某些版本仍可能拒绝索引； - 字段有函数包装，如
WHERE UPPER(name) = 'ABC'，key必为NULL，除非建函数索引（MySQL 8.0+）。
Extra里藏着索引使用真相
Extra字段常暴露索引是否被充分利用：
-
Using index：覆盖索引，只查索引就拿到所有需要字段，不回表； -
Using index condition（ICP）：把部分WHERE条件下推到存储引擎层，在读取索引时提前过滤，减少回表次数； -
Using where; Using index：索引覆盖 + 服务层仍需额外过滤（如对函数结果再判断）； -
Using filesort或Using temporary：即使key有值，也可能因排序/分组逻辑复杂而无法利用索引有序性。
索引命中不是非黑即白，而是一个组合判断过程。盯住key是起点，但必须搭配key_len看用了几列、type看访问方式、Extra看执行细节，才能真实评估索引效率。
