EXPLAIN FORMAT=TREE 是最贴近真实流转的视图，因其直接展示优化器生成的带执行顺序和访问方式的结构化指令树，明确节点输入来源与谓词下推位置。
直接看 EXPLAIN FORMAT=TREE 就能还原整条流转路径，它输出的不是抽象描述，而是优化器实际生成的、带执行顺序和访问方式的结构化指令树。
为什么 EXPLAIN FORMAT=TREE 是最贴近真实流转的视图
MySQL 8.0 的 FORMAT=TREE 模式把优化器输出的执行计划原样展开成嵌套树结构，每一层对应一个物理操作节点，比如 IndexScan、Filter、Sort，连“先扫索引再回表”还是“先过滤再排序”都一目了然。它比传统 EXPLAIN 多两层关键信息：一是明确标出每个节点的输入来源（比如某 Filter 的输入是上层的 TableScan），二是显示谓词下推位置（比如 WHERE age > 25 是在存储引擎层过滤，还是在执行器层过滤）。
- 传统
EXPLAIN只告诉你“用了哪个索引”，但不告诉你“这个索引扫描后是否还要额外过滤” -
FORMAT=TREE会写出> Filter: users.age > 25并缩进在IndexScan下面，说明该条件已下推到引擎层 - 如果看到
Filter出现在最外层，且内部是TableScan，说明没走索引，全表扫完才在执行器做判断
EXPLAIN FORMAT=TREE 能暴露哪些解析/优化阶段的关键决策
它不是执行日志，但能反向印证分析器和优化器干了什么。比如解析器报错（语法/语义）发生在 EXPLAIN 之前；而 EXPLAIN 能跑通，说明解析和预处理已通过。真正能从树里读出来的，是优化器的“选择”：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 看到
IndexScan on users using idx_age→ 优化器选了idx_age而不是主键，说明它评估过age列的选择性 - 看到
-> IndexLookup on users套在IndexScan里面 → 表明走了二级索引 + 回表，而非覆盖索引 - 看到
-> Sort节点独立存在，且输入是IndexScan→ 说明ORDER BY无法利用索引排序，触发了 filesort - 多表 JOIN 出现
NestedLoopJoin或HashJoin节点 → 直接对应优化器选定的连接算法和驱动表顺序
结合 SHOW WARNINGS 看重写后的 SQL，定位解析与预处理行为
执行 EXPLAIN FORMAT=TREE 后立刻跟一句 SHOW WARNINGS，能看到 MySQL 内部重写后的语句。这一步反映的是解析器+预处理器干的活：
- 如果原始 SQL 有视图，这里会显示视图被展开后的等价语句
- 如果有子查询，可能被改写为
JOIN（优化器逻辑重写的结果） - 字段别名、
SELECT *会被展开为具体列名，说明语义解析已完成 - 若出现
Warning | 1292 | Truncated incorrect DOUBLE value类提示，说明预处理阶段发生了隐式类型转换，可能已导致索引失效
容易被忽略的流转断点：权限快照固化与执行器二次校验
整个链路里有两个权限检查点，但只有后者能在执行阶段暴露问题：EXPLAIN 成功不代表真能执行。连接器在校验权限时会把快照固化在 THD 结构里，后续所有操作都基于此；而执行器在真正调用存储引擎前，还会再查一次权限表——如果此时权限已被回收但连接未重连，EXPLAIN 看不出异常，执行时却报 ERROR 1142 (42000): SELECT command denied to user。这不是优化器或引擎的问题，是权限生命周期管理的盲区。
