执行计划在 SQL 解析后、查询优化器阶段生成
MySQL 的执行计划（
EXPLAIN输出结果）不是在客户端拼接 SQL 时生成，也不是在存储引擎读数据时才决定，而是在 Server 层的查询优化器（Query Optimizer）完成逻辑解析和语义检查之后、实际执行之前生成的。具体来说，它发生在：
parser → resolver → optimizer → executor这一链条中的
optimizer阶段。
这个阶段会做：表关联顺序选择、索引选取、访问路径决策（如用
ref还是
range）、是否下推条件、是否使用临时表或文件排序等。执行计划本质上就是优化器输出的「最优执行路径假设」——注意，只是假设，实际执行时仍可能因统计信息过期、并发锁等待、缓冲区不足等原因偏离预期。
为什么 EXPLAIN
有时不反映真实执行行为
EXPLAIN是只做优化器模拟，不真正执行 SQL，因此它无法体现运行时动态因素： 不会触发触发器、不会计算函数字段的实际开销（比如
EXPLAIN SELECT MD5(name) FROM t不评估
MD5()成本） 对子查询、UNION、CTE 的展示有局限：MySQL 8.0+ 才支持
EXPLAIN FORMAT=TREE查看嵌套结构，旧版本常显示为
select_type=DEPENDENT SUBQUERY却不展开内部计划 统计信息陈旧时（如未执行
ANALYZE TABLE），优化器可能选错索引，但
EXPLAIN仍显示“看起来合理”的计划 某些优化（如 MRR、Batch Key Access）在
EXPLAIN中无直接标识，需结合
status变量（如
Handler_read_next）或
performance_schema观察
优化流程中哪些环节容易被跳过或误判
完整 MySQL 查询优化流程包含多个隐式判断点，开发者常只盯着
EXPLAIN的
type和
key字段，却忽略前置环节是否已失效： 如果 SQL 含有无法下推的函数（如
WHERE YEAR(create_time) = 2023），优化器会在条件化简阶段就放弃对
create_time索引的范围扫描，直接退化为全表扫描 —— 此时
EXPLAIN的
key为空，但问题根源不在索引缺失，而在写法 当多表 JOIN 且驱动表选择错误（如小表没走主键，大表被当驱动表），
EXPLAIN显示
type=all，但调换
STRAIGHT_JOIN或加
USE INDEX提示未必生效，因为优化器可能已基于成本模型拒绝提示
SQL_NO_CACHE或
query_cache_type=0不影响执行计划生成，但会掩盖「缓存命中导致慢查询不暴露」的问题；真实慢查要关掉查询缓存再测
如何确认执行计划是否被真正采纳
仅看
EXPLAIN不够，必须交叉验证运行时行为：
SET profiling = 1; SELECT * FROM orders WHERE user_id = 123 AND status = 'paid'; SHOW PROFILES; SHOW PROFILE FOR QUERY 1;
更可靠的方式是启用
optimizer_trace：
SET optimizer_trace="enabled=on,one_line=off"; SELECT * FROM t1 JOIN t2 ON t1.id = t2.t1_id WHERE t1.a > 10; SELECT * FROM information_schema.OPTIMIZER_TRACE\G
它会输出优化器每一步的成本估算、候选索引、最终选择依据。注意：
OPTIMIZER_TRACE有性能开销，仅用于诊断，不可长期开启。
真正复杂的点在于：优化器决策是基于行数估算 + 索引统计 + 硬编码成本常量（如随机磁盘 IO 代价设为 10），这些参数不可见、难调整。一旦统计不准或数据分布倾斜严重，执行计划就容易「看似合理，实则灾难」。
