explain format=tree直接展示优化器真实执行逻辑的树形结构，必须mysql 8.0.16+，含materialize、index range scan等算子节点及嵌套依赖关系，cost和rows为估算值用于横向比较。
EXPLAIN FORMAT=TREE 直接展示优化器决策路径，不是“画树”，而是把真实执行逻辑按层级展开——但必须用 MySQL 8.0.16+，且不能有语法错误或存储过程逻辑干扰。
FORMAT=TREE 能看到什么算子节点
它输出的是逻辑执行树（非标准 AST，但结构高度对应），每个 -> 开头的行是一个算子节点，比如 -> Index range scan on t2 using PRIMARY 或 -> Materialize with deduplication。这些名称直接来自优化器内部迭代器（iterator）命名，反映真实执行动作。
- 常见节点类型包括：
Table scan、Index lookup、Index range scan、Nested loop inner join、Materialize with deduplication、Filter、Sort - 嵌套缩进表示依赖关系：子节点必须等父节点产出数据后才能开始；同一层多个
->表示并行准备（如物化子查询和主表扫描可并行） - 节点末尾的
(cost=2.06 rows=9)是优化器估算值，不等于实际 I/O 次数，但可用于横向比较不同路径代价
为什么 FORMAT=TREE 比传统 EXPLAIN 更适合看 JOIN 和子查询
传统 EXPLAIN 把多表 JOIN 扁平成一行一行，靠 id 和 select_type 推断顺序，容易误读驱动表；而 FORMAT=TREE 显式标出 Nested loop inner join 及其左右子树，谁驱动谁一目了然。
- 对
IN (SELECT ...)类子查询，你会看到Materialize with deduplication节点，说明被转成物化临时表；若没出现，可能走的是semijoin优化，需结合Filter判断是否下推 - CTE 或视图会生成独立子树，但嵌套可能很深，重点看最内层是否含
Index range scan或仍为Table scan - 注意
-> Filter: (t2.b is not null)这类节点位置：如果出现在物化之后，说明过滤在内存中完成；若在索引扫描内（如Index range scan on t2 using PRIMARY (t2.id ），说明下推到了引擎层
FORMAT=TREE 不显示 key_len、rows_estimation 等字段，怎么补足
它刻意省略了传统格式里关键的索引长度、预估扫描行数等字段，所以不能单靠它判断索引是否用全。必须配合传统格式交叉验证。
- 先运行
EXPLAIN FORMAT=TREE your_sql看结构和顺序 - 再运行
EXPLAIN your_sql（默认 TRADITIONAL）查key_len、rows、Extra（如Using index condition） - 若发现
FORMAT=TREE中有Index lookup on t1 using a，但传统格式里key_len明显偏小（如定义VARCHAR(255)却只用 10 字节），说明用了前缀索引，实际 B+Tree 分支因子变小，可能影响性能 - 遇到
Using temporary; Using filesort，FORMAT=TREE可能只显示Sort节点，但看不到 sort_buffer 是否溢出——这时得查SHOW STATUS LIKE 'Sort%'或开启 optimizer_trace
EXPLAIN ANALYZE 和 FORMAT=TREE 的关键区别在哪
EXPLAIN ANALYZE 是 FORMAT=TREE 的执行版：它真跑 SQL，并在每个算子后追加 (actual time=0.035..0.038 rows=9 loops=1)。这让你一眼看出哪步最慢、哪步循环最多。
-
actual time是真实耗时（单位毫秒），但注意：首次执行受 buffer pool 冷启动影响，建议多次执行取稳定值 -
loops值高（如loops=9）往往意味着嵌套循环次数多，是 JOIN 顺序或条件过滤不足的信号 - 它不支持带写操作的语句（
INSERT/UPDATE/DELETE），也不支持某些含用户变量的查询；报错时切回FORMAT=TREE或传统格式 - 别混淆
cost（优化器估算）和actual time（真实耗时）：前者用于选执行计划，后者用于定位瓶颈——两者偏差大，说明统计信息过期，该ANALYZE TABLE了
真正难的是把树状结构和物理 I/O 对应起来：比如看到 Index lookup on t1 using a，得立刻反应这是“一次二级索引 B+Tree 查找 + 可能的回表”，而树高本身无法直接读出，只能靠 rows 估算和 key_len 反推。别指望一棵树解决所有问题，它只是把黑盒打开了一条缝。
