SQL 是声明式语言，写法不等于执行路径。MySQL 拿到一条语句后，必须先把文本解析成内部结构，再结合统计信息选择访问路径，最后由执行器按计划调用存储引擎。
很多慢查询排查之所以绕远，是因为把 SQL 文本当成了真实执行过程。这一篇关注分析器、优化器和执行器的分工：它们分别决定“能不能执行”“准备怎么执行”和“实际怎么取数据”。
先把机制边界说清楚
分析器负责把 SQL 文本变成 MySQL 能理解的内部结构，并检查表、列、函数和权限；优化器负责在多个可行路径中选择成本最低的执行计划；执行器负责按计划调用存储引擎，一行一行或一批一批拿数据。
整体路径
上面这张图先看入口和边界：宏观上，Server 层的中间流水线像一个编译执行过程：SQL 文本先变成语法树，再解析成查询块和表达式；优化器结合统计信息生成候选计划并估算成本；执行器拿到最终计划后，通过 handler 接口驱动 InnoDB 访问数据。
第二张图再看结构关系。
底层流程
底层拆解先看数据结构。「分析器、优化器、执行器」至少涉及下面几类结构：
- 语法树：表达 SQL 的结构化结果。
- 查询块：子查询、派生表和连接关系的优化单位。
- 统计信息：表大小、索引基数、直方图和页数估算。
- 成本模型：把扫描、回表、排序和临时表折算成可比较代价。
- 执行计划：最终被执行器消费的访问路径。
再看完整执行流程：
- 分析器检查 SQL 语法和语义。
- 预处理阶段解析表、列、函数和权限。
- 优化器枚举候选索引、连接顺序和执行方式。
- 成本模型选择一条计划。
- 执行器按计划调用存储引擎并返回结果。
取舍与边界
版本差异上，MySQL 8.0 在直方图、EXPLAIN ANALYZE、优化器 trace、窗口函数和 CTE 等方面增强很多。5.7 也有成本优化器，但可观测性弱一些。版本越新，不代表计划永远正确，只是你更容易看到它为什么这样选。
优化器最大短板是它依赖估算。统计信息过期、数据分布倾斜、多个条件强相关、函数包裹索引列，都会让估算偏离真实执行成本。执行器只是忠实执行计划，计划错了，后面越努力越慢。
典型问题：用机制化例子排查
优化器误判可以用数据倾斜来理解：同一个字段在平均分布下看起来选择性很好，但某个热点值可能对应大量记录，实际回表成本远高于估算。问题不在 SQL 文本，而在执行路径。
可以落到这些动作：
- 读 EXPLAIN 时先还原访问路径，不要逐字段背定义。
- 对比 rows 估算和真实扫描量，判断是否统计信息失真。
- MySQL 8.0 优先用 EXPLAIN ANALYZE 校准计划。
- 长期方案应通过索引、SQL 形态和数据模型让正确计划更容易被选中。
收束：SQL 写法不等于执行路径
分析器、优化器、执行器决定了 SQL 从“你想要什么”变成“数据库怎么做”。理解这条流水线，才能解释为什么同一张表、同一个索引，在不同 SQL 下表现完全不同。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MySQL」，欢迎关注公众号 「十三Tech」。后续会继续按机制、图解和实战排查这条线更新。
