SQL执行流程到底影响哪些优化动作
理解 MySQL 的 SQL 执行流程不是为了背诵“词法分析→语法分析→优化器→执行器”这串名词，而是为了定位真实瓶颈。比如你看到
EXPLAIN输出里
type是
ALL，就知道扫描了全表——这直接对应执行流程中“优化器没选上索引”或“存储引擎层没走索引查找”，而不是盲目加索引或改写 WHERE 条件。
优化器阶段最容易被误判的三个地方
很多慢查询优化失败，是因为把问题归错阶段。优化器决定用哪个索引、是否走索引合并、是否下推条件，但它的决策依赖准确的统计信息和明确的语义。以下情况常导致优化器“选错”：
WHERE中对索引列用了函数，比如
WHERE YEAR(create_time) = 2023，优化器无法使用
create_time索引（除非是函数索引） 隐式类型转换，比如
WHERE user_id = '123'（
user_id是
INT），MySQL 可能放弃索引而转为全表扫描 统计信息过期，
ANALYZE TABLE没跑过，优化器基于错误行数估算选择嵌套循环而非哈希连接（在 8.0+ 中影响更大）
执行器与存储引擎协作时的性能盲区
执行器负责调用存储引擎接口取数据，但它不关心数据怎么存、怎么读——这部分由引擎（如 InnoDB）实现。这就带来几个关键断点：
执行器每调一次ha_index_read()或
ha_rnd_next()，都可能触发一次磁盘 I/O（若缓冲池未命中）
ORDER BY无可用索引时，执行器会要求引擎返回所有匹配行，再在 Server 层做文件排序（
Using filesort），内存不足就写临时文件
LIMIT不一定减少 I/O：如果
WHERE条件匹配前 1000 行都在表尾，InnoDB 仍要从头扫到尾才能凑够 10 条满足
LIMIT 10
什么时候该看执行流程，什么时候不必深究
日常优化中，90% 的慢查靠
EXPLAIN+
SHOW PROFILE+ 慢日志就够了；只有遇到这几类问题才需要回溯执行流程： 同样 SQL 在测试库快、生产库慢，且
EXPLAIN结果一致 → 检查优化器开关（如
optimizer_switch）、统计信息、缓冲池大小差异 加了索引却没生效，
EXPLAIN显示
key为空 → 看是否触发了索引失效规则（如最左前缀未匹配、范围查询后列失效） 观察到大量
Handler_read_next或
Handler_read_rnd_next增长 → 说明执行器在反复调用引擎接口，大概率是索引覆盖不全或排序/分组未走索引
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 10;
这条语句如果
status和
created_at没有联合索引，InnoDB 就得先扫所有
status = 'paid'行，再在 Server 层排序——流程上多了一次数据搬运和内存排序，比建个
(status, created_at)索引慢几倍很正常。流程清楚了，优化方向就非常具体。
