MySQL EXPLAIN执行计划解析与优化指南

调用 EXPLAIN 的基本方法

要在 MySQL 中查看查询的执行计划，只需在标准 SELECT 语句前添加 EXPLAIN 关键字。MySQL 会在不实际执行查询逻辑的前提下，模拟优化器的决策过程，返回每一步的执行细节。这对于复杂的查询分析至关重要，因为直接运行慢查询会影响线上业务稳定性。

注意： EXPLAIN 主要用于 SELECT 语句。在 MySQL 5.6 及更高版本中，它也开始支持对 INSERT、UPDATE、DELETE 等非 SELECT 语句的简单解释。此外，还有两个常用变种：
- EXPLAIN EXTENDED：提供更详细的中间步骤信息，可配合 Show WARNings 查看重写后的 SQL。
- EXPLAIN PARTITIONS：针对分区表，显示查询具体访问了哪些分区。

尽管 EXPLAIN 非常有用，但它存在局限性。例如，它无法准确反映存储过程、触发器或用户自定义函数（UDF）的影响，且对于包含子查询或临时表的复杂情况，其估算的行数可能与实际执行有偏差。因此，应将其作为优化的参考依据之一，而非绝对真理。

EXPLAIN 输出列详解

EXPLAIN 的结果集包含多列，每一列都提供了关于查询执行的不同维度的信息。以下是核心字段的深度解析及优化建议。

第1步：解析 id — 确定执行顺序

id 列标识了当前行所属的 SELECT 查询块。如果查询中没有子查询或 UNION，所有行的 id 均为 1。当存在子查询或 UNION 时，id 会按嵌套层次递增。

• id 越大优先级越高： 子查询内部的 SELECT 通常拥有更大的 id，意味着它们会更早被执行。
• id 相同从上到下： 如果多行 id 相同，则按照在文本中出现的顺序从上至下依次执行。
• id 为 NULL： 通常出现在 UNION 结果集的最后一行，表示这是一个临时表的检索操作，不在原始 SQL 结构中体现。

示例：UNION 查询的 EXPLAIN 结果，注意 id 分布与 NULL 值位置

第2步：解析 select_type — 识别查询结构

select_type 说明了该行对应的查询类型，帮助判断是否发生了非预期的临时表创建或重复计算。

• SIMPLE：最简单的查询，不含子查询或 UNION。
• PRIMARY：最外层查询。若子查询被标记为 DERIVED，最外层通常会升格为 PRIMARY。
• SUBQUERY：子查询位于 SELECT 列表中，不依赖外部表。
• DERIVED：派生表查询。FROM 子句中的子查询会将结果存入临时表，后续再连接主表。此类查询往往性能较差，应尽量避免。
• UNION / UNION RESULT：涉及联合查询的场景。

示例：单表查询的 EXPLAIN 结果，通常为 SIMPLE 类型

第3步：解析 table — 确认访问目标

table 显示了当前行正在访问的具体表名或别名。如果是派生表（DERIVED），这里会显示 <derivedN>，其中 N 对应 id 列的值。这是观察 MySQL 关联顺序（Join Order）的关键列，MySQL 会从左到右处理这些表。

第4步：解析 type — 评估访问性能（关键）

type 是衡量查询性能最重要的指标之一，表示 MySQL 找到所需记录的方式。性能从差到好的一般排序如下：

• ALL（最差）：全表扫描。应极力避免，除非表极小或必须获取全部数据。
• index：全索引扫描。比 ALL 稍好，因为它按索引顺序读取，但开销依然巨大。
• range：范围扫描。仅查找给定范围内的行，如使用 BETWEEN、>、< 等操作符。这是常见的优化目标。
• ref：等值匹配的非唯一索引查找。常用于 = 或 <=> 操作。
• eq_ref：唯一性索引查找。每个索引键只匹配一行，性能极高，常见于主键或唯一键关联。
• const/system：常量级访问。当查询条件定位到主键或唯一索引时，MySQL 可将该查询转换为常量，速度最快。
• NULL：无需访问表或索引，通常在聚合函数（如 MIN()）直接从索引获取最小值时使用。

优化提示： 我们的目标是让 type 至少达到 ref 级别，最好能实现 eq_ref 或 const。如果出现 ALL，请检查 WHERE 条件的字段是否有合适的索引。

第5步：解析 possible_keys 与 key — 分析索引选择

possible_keys 列出优化器认为可能用到的索引；key 列则显示实际选用的索引。如果 key 为 NULL，说明未使用任何索引。

• 若 possible_keys 中有候选索引，但 key 未选中，可能是因为代价估算认为全表扫描更便宜，或者索引选择性太差。
• 可以通过 FORCE INDEX、USE INDEX 强制指定，但需谨慎测试。

第6步：解析 key_len — 验证索引利用度

key_len 表示使用的索引字节数。它反映了复合索引中被使用的“前缀”长度。

• 可以根据字段定义计算出预期长度，并与实际 key_len 对比。例如，一个 VARCHAR(20) UTF8MB4 字段理论长度为 80 字节，若 key_len 仅为 4，说明该字段并未参与索引过滤。
• 允许为 NULL 的字段，索引长度会比 NOT NULL 多 1 字节用于标记空值。

第7步：解析 rows — 估算扫描行数

rows 是优化器预估需要扫描的记录数。虽然仅是估算，但它能直观反映查询的工作量。在多表 Join 时，总工作量大致为各行 rows 值的乘积。注意，受统计信息准确性影响，该数值可能存在偏差。

第8步：解析 Extra — 获取附加信息

Extra 提供了额外的关键诊断信息，是判断是否需要优化的重要依据：

• Using index（极好）：覆盖索引。查询所需的列完全包含在索引中，无需回表查数据。
• Using index condition（良好）：索引下推（ICP）。在存储引擎层先做部分过滤，减少回表次数，MySQL 5.6+ 特性。
• Using where（需关注）：存储引擎已返回数据，但在 Server 层根据 WHERE 条件进行了过滤。表明可能缺少有效索引或使用不当。
• Using temporary（警告）：使用了临时表，常见于 GROUP BY、DISTINCT 或 ORDER BY 无法走索引的情况。通常建议优化索引。
• Using filesort（警告）：文件排序。MySQL 无法利用索引有序性进行排序，需额外进行排序操作。可通过调整索引顺序避免。
• Distinct：优化器一旦找到第一个匹配项即停止搜索当前剩余项，常用于去重查询。

总结与优化建议

掌握 EXPLAIN 是 SQL 调优的第一步。在实际操作中，应重点监控 type 和 Extra 列。优先消除 ALL 和 Using temporary/filesort，争取达到 ref 及以上水平，并利用覆盖索引减少 I/O 开销。对于复杂查询，建议逐步拆解并在开发环境中进行 EXPLAIN 验证，确保索引设计符合查询需求。

以上就是 MySQL EXPLAIN 执行计划解析与优化的详细内容，更多关于 MySQL 数据库性能调优的资料请关注本站其它相关文章！