MySQL执行计划在查询优化器阶段生成，即parser→resolver→optimizer→executor链条中的optimizer环节，负责关联顺序、索引选择、访问路径等决策，本质是基于统计信息的最优路径假设。
执行计划在 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），这些参数不可见、难调整。一旦统计不准或数据分布倾斜严重，执行计划就容易「看似合理，实则灾难」。
