MySQL 8.0 中SQL执行流程为：连接器→分析器→优化器→执行器；查询缓存已移除，分析器负责语法与语义校验，优化器通过EXPLAIN和OPTIMIZER_TRACE展现决策，执行器行为需借助performance_schema间接验证。
MySQL 8.0 中无法直接“回放”一条 SQL 的完整执行流程（比如像调试器单步执行那样），但你可以分阶段、用不同命令观察关键环节的内部行为。核心思路是：**绕过已移除的查询缓存，聚焦分析器、优化器、执行器三层的输出证据**。
怎么看词法/语法解析是否成功？
错误发生在分析器阶段，现象最直接：SQL 一提交就报错，且不涉及表数据或索引。
- 典型错误信息：
You have an error in your SQL syntax、Unknown column 'xxx'（列名拼错）、Unknown table 'xxx'（表不存在）——这些都在分析器或预处理器阶段被拦截，根本不会走到优化器 - 注意：
Unknown database 'xxx'是连接器阶段失败，连 Server 层都没进 - 验证方式：把语句粘贴进 MySQL CLI 或客户端执行，看报错位置和类型；不要依赖 IDE 的语法高亮，它不等价于 MySQL 实际解析逻辑
怎么确认优化器选了哪个执行计划？
EXPLAIN 是唯一可靠入口，它展示优化器决策后的结果，不是“过程”而是“快照”。
- 必须用
EXPLAIN FORMAT=TRADITIONAL或EXPLAIN FORMAT=JSON，后者字段更全（如used_columns、key_length、rows_examined_per_scan） - 重点看
type（访问类型）、key（实际使用的索引）、rows（预估扫描行数）、filtered（条件过滤率）——这些值直接受统计信息、索引结构、WHERE 条件写法影响 - 避免陷阱：不要只看
Extra里有没有Using index，还要结合key是否为NULL；Using filesort不一定慢，但说明排序没走索引
怎么看到优化器内部的决策细节？
OPTIMIZER_TRACE 是 MySQL 8.0 唯一能暴露优化器“思考过程”的机制，但它默认关闭，且有严格使用边界。
- 启用前必须先执行：
SET optimizer_trace="enabled=on"，并建议加,one_line=off方便阅读 - 执行目标 SQL 后，查
SELECT * FROM information_schema.OPTIMIZER_TRACE—— 注意：只保留最近一次 trace，且仅对当前会话有效 - 关键字段：
steps数组里能看到“range_analysis”（范围分析）、“considered_execution_plans”（候选计划打分）、“attaching_conditions_to_tables”（条件下推）等真实决策节点 - 限制很实在：trace 输出巨大（尤其多表 JOIN），且不包含执行器调用存储引擎的具体 I/O 行为；
INSERT/UPDATE/DELETE的 trace 内容比SELECT少得多
执行器干了什么？只能间接推测
执行器本身不提供日志开关，它的行为需靠组合手段交叉验证。
-
SHOW PROFILE在 MySQL 5.7 及以前可用，8.0 已废弃；现在只能依赖性能模式（performance_schema） - 开启相关 consumers：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events%statement%'; - 然后查
performance_schema.events_statements_history_long，过滤你的 SQL 的DIGEST_TEXT，看LOCK_TIME、ROWS_AFFECTED、ROWS_SENT等字段——这些是执行器最终交出的结果，但看不到它怎么调用 InnoDB 接口 - 真正底层动作（如是否用了 Change Buffer、Undo Log 怎么写）只能通过
innodb_status或 redolog/buffer pool 监控指标间接反推
复杂点在于：每个环节输出都是静态快照或事后汇总，没有时序化流水日志；OPTIMIZER_TRACE 开销大、难读，performance_schema 需要提前配置且默认关；而执行器这一层，MySQL 故意没留“透明窗口”——它只保证结果正确，不承诺让你看见每一步怎么走的。
