key字段表示优化器实际使用的索引名,但需结合type、key_len、rows和Extra综合判断是否有效命中;key非NULL不等于高效,可能仅部分命中或仅用于排序/分组。

SQL执行计划里的key字段,直接告诉你优化器**实际使用了哪个索引**。它不等于“有没有建索引”,也不代表“一定高效”,而是执行时真正拿去查找数据的那个索引名。判断是否命中索引,不能只看key是否为NULL,还要结合type、key_len、rows和Extra一起看。
即使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反映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,这往往意味着:发生了类型隐式转换,导致索引失效。典型场景:
VARCHAR,但查询写成WHERE col = 123(数字)→ MySQL转成WHERE CAST(col AS SIGNED) = 123,无法走索引;CHAR(10)带空格,而参数传入'abc'(无空格),比较时补空格,但某些版本仍可能拒绝索引;WHERE UPPER(name) = 'ABC',key必为NULL,除非建函数索引(MySQL 8.0+)。Extra字段常暴露索引是否被充分利用:
Using index:覆盖索引,只查索引就拿到所有需要字段,不回表;Using index condition(ICP):把部分WHERE条件下推到存储引擎层,在读取索引时提前过滤,减少回表次数;Using where; Using index:索引覆盖 + 服务层仍需额外过滤(如对函数结果再判断);Using filesort或Using temporary:即使key有值,也可能因排序/分组逻辑复杂而无法利用索引有序性。索引命中不是非黑即白,而是一个组合判断过程。盯住key是起点,但必须搭配key_len看用了几列、type看访问方式、Extra看执行细节,才能真实评估索引效率。
以上就是SQL执行计划中key字段说明_索引命中判断技巧【技巧】的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号