看 EXPLAIN 不能像背字段说明书。id、type、key、rows、Extra 都重要，但它们最终服务于一个问题：MySQL 准备怎样访问数据。
执行计划不是实际执行日志，而是优化器给出的访问方案。读它的顺序应该是：从哪张表开始，怎么访问，用哪个索引，预计扫多少行，是否还要排序、临时表或回表。
先把机制边界说清楚
EXPLAIN 是 MySQL 对“准备怎么执行这条 SQL”的解释。它不是实际执行日志，而是执行前的计划。核心不是背字段，而是还原访问路径：从哪张表开始，怎么访问，用哪个索引，预计扫多少行，是否还要排序、临时表或回表。
整体路径
上面这张图先看粗线条：宏观上，执行计划把 SQL 从声明式语句翻译成过程式路径。Server 层先解析和改写 SQL，优化器生成候选计划并估算成本，选出计划后执行器调用存储引擎。EXPLAIN 展示的是这条路径的骨架。
底层流程
底层拆解先看数据结构。「执行计划」至少涉及下面几类结构：
- 访问类型 type：描述从 const 到 ALL 的访问粒度。
- key 与 possible_keys：候选索引和最终索引选择。
- rows 与 filtered：优化器对扫描量和过滤率的估算。
- Extra：额外执行动作，如 filesort、temporary、index condition。
再看完整执行流程：
- 对 SQL 做语法解析和语义检查。
- 生成候选访问路径。
- 根据统计信息估算每条路径成本。
- 选择计划并输出 EXPLAIN 字段。
- 实际执行时可能受运行时数据和缓存状态影响。
取舍与边界
版本差异上，MySQL 8.0 的 EXPLAIN 支持 FORMAT=JSON、EXPLAIN ANALYZE 等更强能力，后者能看到实际执行耗时和行数。5.7 时代更多依赖传统 EXPLAIN 和慢查询日志结合判断。
EXPLAIN 的短板是它展示的是计划，不等于真实执行全过程。rows 是估算，不是实际值；Extra 是信号，不是结论；小表全表扫可能没问题，大表 range 也可能很慢。
典型问题：用机制化例子排查
执行计划适合用来还原访问路径：从哪张表开始，走哪个索引，预计多少行，是否回表、排序或临时表。字段要看，但不要停在字段解释。
可以落到这些动作：
- 阅读顺序固定为 table/type/key/rows/Extra，不要平均用力。
- 看到 Using filesort 和 Using temporary，要结合数据量判断是否需要索引顺序。
- MySQL 8.0 优先用 EXPLAIN ANALYZE 校准估算和实际。
- 把执行计划变化纳入发布检查，避免加索引或改 SQL 后计划漂移。
收束：EXPLAIN 是访问路径说明
EXPLAIN 的价值不在背字段，而在还原访问路径。能从计划里看出扫描、回表、排序和临时表，慢查询排查才算真正进入数据库内部。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MySQL」，欢迎关注公众号 「十三Tech」。后续会继续按机制、图解和实战排查这条线更新。
