MySQL EXPLAIN 详解

一、EXPLAIN 是什么？

EXPLAIN 是 MySQL 提供的性能分析工具，用于检察 SQL 查询的执行计划（即优化器怎样执行查询）。它通过模拟查询过程（不实际执行 SQL）返回一个表格，展示索引利用、表连接方式、扫描行数等关键信息，资助开辟者诊断性能瓶颈并优化查询。
核心作用：

• 分析查询是否高效利用索引。
  
• 识别全表扫描、临时表、文件排序等高开销操纵。
  
• 提供优化方向，如调整索引或重构 SQL。
  

---

二、为什么要用 EXPLAIN？

• 性能调优：快速定位慢查询原因，比方未命中索引（type=ALL）或大量行扫描（rows值过高）。
  
• 索引验证：检查索引是否被实际利用（key列），避免冗余或低效索引。
  
• 查询重构：根据连接范例（type列）和额外信息（Extra列）优化复杂查询逻辑。
  

---

三、怎样利用 EXPLAIN？

根本语法：

1. EXPLAIN [FORMAT=TRADITIONAL|JSON|TREE] SELECT ...;

复制代码

• FORMAT：指定输出格式，默认是表格形式（TRADITIONAL），JSON 格式包含更详细信息。
  

示例：

1. EXPLAIN SELECT * FROM users WHERE age > 30;

复制代码

输出结果示例：
idselect_typetabletypepossible_keyskeykey_lenrowsExtra1SIMPLEusersrangeageage41000Using where

---

四、执行计划指标详解

1. id

• 含义：查询中每个子查询或操纵的唯一标识符。
  
• 规则：
  
  
  
  • 相同 id：按从上到下顺序执行。
    
  • 差别 id：数值越大优先级越高（如子查询优先执行）。
    
  
  

2. select_type

• 常见范例：
  
  
  
  • SIMPLE：简单查询（无子查询或 UNION）。
    
  • PRIMARY：最外层查询。
    
  • SUBQUERY：子查询中的 SELECT。
    
  • DERIVED：派生表（如 FROM 子句中的子查询）。
    
  
  

3. type

• 性能排序（从优到劣）：
  system > const > eq_ref > ref > range > index > ALL。
  
• 关键范例说明：
  
  
  
  • const：通过主键或唯一索引查询单条记录（如 WHERE id=1）。
    
  • eq_ref：多表关联时，主键或唯一索引的等值匹配（如 JOIN 中主键关联）。
    
  • ref：非唯一索引的等值匹配（可能返回多行）。
    
  • range：索引范围扫描（如 BETWEEN、IN）。
    
  • ALL：全表扫描，需优化索引或查询条件。
    
  
  

4. key 与 possible_keys

• possible_keys：可能利用的索引（若为 NULL，表示无符合索引）。
  
• key：实际利用的索引。若未命中索引（key=NULL），需检查 WHERE 条件或添加索引。
  

5. rows

• 含义：预估需要扫描的行数。若值过大，可能需优化索引或过滤条件。
  

6. Extra

• 关键信息：
  
  
  
  • Using index：覆盖索引（无需回表查询数据）。
    
  • Using filesort：额外排序（需优化 ORDER BY 或索引）。
    
  • Using temporary：利用临时表（常见于 GROUP BY 或复杂 JOIN）。
    
  
  

指标含义常见值/说明id查询的序列号（子查询执行顺序）数值越大越先执行；相同 id 按从上到下顺序执行。select_type查询范例SIMPLE（简单查询）、PRIMARY（外层查询）、SUBQUERY（子查询）等。table当前操纵的表名表名或别名，可能为 <derivedN>（派生表）或 <unionN>（UNION 结果）。type访问范例（性能关键指标）const（主键）、ref（索引）、range（范围索引）、ALL（全表扫描）等。possible_keys可能利用的索引优化器评估可选的索引，若为 NULL 表示无可用索引。key实际利用的索引若为 NULL 表示未利用索引。key_len索引利用的字节数长度越短效率越高（比方复合索引是否完整利用）。rows预估需要扫描的行数数值越大性能越差（需联合过滤条件判断）。Extra额外信息（紧张优化线索）Using index（覆盖索引）、Using where（过滤）、Using filesort（排序）等。

---

五、不利用 EXPLAIN 可能出现的题目

• 性能瓶颈难以定位
  
  
  
  • 无法快速发现未命中索引的全表扫描（type=ALL），导致查询迟钝。
    
  • 无法识别高开销操纵（如 Using filesort 或 Using temporary），影响团体性能。
    
  
  
• 索引优化盲目性
  
  
  
  • 可能创建冗余或低效索引（比方对低选择性字段建索引），浪费存储资源。
    
  • 无法验证索引是否实际生效，导致“假优化”。
    
  
  
• 资源浪费与扩展性题目
  
  
  
  • 未优化的查询可能大量占用 CPU、内存和磁盘 I/O，降低服务器吞吐量。
    
  • 复杂查询（如多表 JOIN 或子查询）可能因执行计划不佳，导致体系在高并发下崩溃。
    
  
  
• 维护资本高
  
  
  
  • 慢查询日记只能发现“已发生”的题目，而 EXPLAIN 能预防潜在性能风险。
    
  • 缺乏执行计划分析时，代码重构或数据库升级轻易引入性能退化。
    
  
  

---

六、总结

• 必用 EXPLAIN 的场景：
  
  
  
  • 新上线 SQL 语句的性能验证。
    
  • 慢查询日记中发现的低效 SQL 分析。
    
  • 复杂 JOIN 或子查询的优化。
    
  
  
• 快速优化步骤：
  
  
  
  • 检查 type 是否为 ALL（全表扫描） → 思量添加索引。
    
  • 检查 Extra 是否有 Using filesort 或 Using temporary → 优化排序或 GROUP BY。
    
  • 检查 rows 是否远大于实际输出行数 → 优化 WHERE 条件或索引。
    
  
  

通过 EXPLAIN 分析，可将模糊的“慢查询”转化为具体的优化动作，大幅提升数据库性能！

• MySQL 官方文档
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。