如何在 SQL 中利用 EXPLAIN 关键字分析查询语句的执行计划以寻找性能瓶颈
作者:EasyWind
时间:2026-07-08
浏览:0
通过EXPLAIN分析SQL执行计划,重点关注type避免ALL全表扫描,key确认索引生效,rows估算扫描行数,Extra捕捉filesort、temporary等隐藏开销,从而定位性能瓶颈并优化。
搞数据库优化的人都知道,查询慢是线上最头疼的问题之一。而 EXPLAIN 就是数据库给你的“查案报告”——它把执行计划摊开给你看,哪里慢、为什么慢,一目了然。但光看报告还不够,关键得知道怎么看重点。来,直接说干货。
直接在 SELECT 语句前加上 EXPLAIN,数据库就会告诉你它“打算怎么查”,而不是真去跑一遍。你不需要逐字段全读,盯住几个关键点就够了——它们会直接暴露瓶颈在哪。
看 type 字段:识别访问效率高低
这是判断查询快慢最核心的指标,值的顺序从优到劣依次是:const → eq_ref → ref → range → index → ALL。
- ALL 出现就敲警钟:全表扫描,数据量一上去,性能直接断崖下跌。
- index 是全索引扫描,比 ALL 好一些,但仍有优化空间。
- range 表示用索引做了范围查找(比如
age > 30),属于合理状态。 - ref 或 eq_ref 是理想情况,说明通过非唯一/唯一索引精准定位到了数据行。
看 key 和 possible_keys 字段:确认索引是否生效
这两个字段得一起看,才能判断索引有没有被“用对”。
- key 为 NULL:没走任何索引。即便建了索引,也可能因为写法问题失效(比如对字段用了函数、或者隐式类型转换)。
- possible_keys 有值,key 为空:索引存在,但优化器认为不值得用——可能是统计信息不准,或者索引选择性太差。
- key 显示具体索引名:说明索引被采纳了,再结合 type 和 rows 判断是否高效即可。
看 rows 字段:估算扫描代价
这个数字是 MySQL 预估要检查的行数,可不是最终返回的结果数。
- 如果 rows 达到几万甚至更多,而实际只返回几十行,大概率存在过滤效率低或索引未覆盖全部条件的问题。
- 对比 WHERE 条件中的字段顺序与复合索引的列顺序——必须满足最左前缀原则,否则索引可能只用上一部分。
- 如果 rows 远大于实际匹配行数,不妨试试更新统计信息:
ANALYZE TABLE table_name。
看 Extra 字段:捕捉隐藏开销
这里藏着很多“悄悄吃资源”的操作,尤其要留意下面几种信号:
- Using filesort:ORDER BY 无法利用索引排序,需要额外内存或磁盘排序,代价较高。
- Using temporary:GROUP BY、DISTINCT 或某些 JOIN 触发了临时表,I/O 和内存压力都会变大。
- Using where:正常现象,表示存储引擎返回数据后还需要服务器层做过滤。
- Using index:好消息!说明走了覆盖索引,无需回表查数据,性能优秀。
作者最新文章
淘宝闪购“等灯不计时”机制解析:政策、技术与多方协同
2026-09-08 18:00
一加自研电竞三芯P4/G3/T3确认:一加16首发,支持185FPS及9000mAh电池
2026-09-08 16:52
抖音拍摄剪辑教程:从竖屏运镜到卡点成片
2026-09-03 06:05
Excel筛选大于指定数值:操作步骤与结果验证
2026-09-03 06:03
PDF添加文字水印:位置、透明度与字号设置指南
2026-09-03 06:01
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多


































