如何在 SQL 中利用 EXPLAIN 关键字分析查询语句的执行计划以寻找性能瓶颈

搞数据库优化的人都知道，查询慢是线上最头疼的问题之一。而 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：好消息！说明走了覆盖索引，无需回表查数据，性能优秀。