SQL执行计划中key字段说明_索引命中判断技巧【技巧】

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看执行细节，才能真实评估索引效率。