MySQL Explain详解：执行计划字段含义与优化指南

语法与基本用法

在SQL语句前添加`EXPLAIN`关键字即可获取该查询的执行计划。例如：

EXPLAIN SELECT * FROM table_name WHERE id = 1;

执行后返回的结果集包含多个列，用于描述MySQL如何解析和执行该SQL。

EXPLAIN 输出字段详解

第1步：理解 ID 列——查询执行顺序

目的：确定子查询或联合查询中各部分的执行优先级。
说明：ID 值越大，优先级越高，越先执行；如果 ID 相同，则从上到下依次执行。在复杂的多表关联或子查询中，ID 可以帮助理清逻辑。
示例：嵌套子查询中，内层子查询 ID 较大，会优先被处理为派生表。

第2步：识别 SELECT_TYPE —— 查询类型

目的：区分简单查询、子查询、联合查询等不同类型。
入口：查看 select_type 列的值。
常见类型：

• SIMPLE：简单的 SELECT 查询，不使用子查询或 UNION。
• PRIMARY：如果查询包含子查询，最外层的 SELECT 标记为 PRIMARY。
• SUBQUERY：在 SELECT 或 WHERE 列表中包含的子查询。
• DERIVED：衍生表的 SELECT（FROM 子句中的子查询）。
• UNION：UNION 语句中第二个及之后的 SELECT。
• UNION RESULT：从 UNION 结果集中选取行的阶段。

第3步：确认 TABLE —— 涉及的数据表

目的：识别当前行对应的是哪张物理表或派生表。
说明：如果是 <derivedN> 格式，表示这是由 ID 为 N 的子查询生成的临时表。这有助于追踪数据流转路径。

第4步：分析 TYPE —— 访问类型（核心指标）

目的：评估查询效率的关键列，显示 MySQL 如何查找表中的行。性能从好到差大致排序如下：

• system：表只有一行记录（等于系统表），是 const 的特例，极快。
• const：表最多有一行匹配记录，很快。通常用于主键或唯一索引的所有部分作为常量比较时（如 WHERE primary_key = 1）。
• eq_ref：对于前面的表的每一行，本表读取一行记录。这是除 system/const 外最好的连接类型，通常用于主键或唯一索引的精确匹配。
• ref：非唯一或非主键索引，或最左前缀索引。对于每个匹配索引值的行，都会读取一行。比 eq_ref 稍慢，但仍优于范围扫描。
• fulltext：使用全文索引。
• ref_or_null：类似 ref，但增加了搜索包含 NULL 值的行。
• index_merge：使用了索引合并优化方法，结合了多个索引。
• unique_subquery：用于 IN 子查询的高效替代形式。
• index_subquery：类似 unique_subquery，但用于非唯一索引子查询。
• range：只检索给定范围的行，使用索引选择行。常用于 BETWEEN、>、<、IN 等操作符。
• index：全索引扫描。比 ALL 快，因为只需扫描索引树，适合查询仅涉及索引列的情况。
• ALL：全表扫描。性能最差，应尽量避免。如果未命中索引，通常会出现此类型。

第5步：检查 EXTRA —— 附加信息

目的：获取 MySQL 解决查询的详细信息，发现潜在的性能问题。
常见警告：

• Using index：覆盖索引，无需回表，性能好。
• Using where：服务器层对存储引擎返回的行进行过滤。如果连接类型为 ALL 或 index，可能需要优化索引。
• Using filesort：需要额外的排序步骤，性能开销较大，通常因 ORDER BY 缺乏合适索引导致。
• Using temporary：使用临时表保存中间结果，常见于 GROUP BY 或 DISTINCT，需优化以减少临时表创建。
• Distinct：MySQL 找到第一个匹配行后即停止搜索后续重复项。
• Not exists：MySQL 优化了 LEFT JOIN，一旦找到匹配行即停止。

总结

通过分析 EXPLAIN 结果中的 type 和 extra 字段，可以快速定位 SQL 执行效率低下的原因。优先确保查询走 const、eq_ref 或 ref 级别，避免全表扫描（ALL）和不必要的排序（filesort）。定期审查关键查询的执行计划，结合业务场景调整索引策略，是维持数据库高性能运行的关键手段。

以上就是 MySQL Explain 命令详解及执行计划解读的详细内容，更多关于 SQL 性能优化的资料请关注本站其它相关文章！