EXPLAIN FORMAT=JSON能暴露逻辑树结构，其嵌套JSON中的"children"数组明确表达算子父子依赖关系，如HASH JOIN节点包含左右输入TABLE_SCAN，本质是未渲染的执行计划树，需解析而非图形化查看。
EXPLAIN FORMAT=JSON 能看到逻辑树结构吗
不能直接看到“树形图”，但 EXPLAIN FORMAT=JSON 是 MySQL 中唯一能暴露优化器内部决策层级结构的方式。它输出的是嵌套 JSON，每个 plan 节点包含 children 数组，本质上就是一棵执行计划树 —— 只是没渲染成图形，而是以字段关系表达父子算子依赖。
比如 HASH JOIN 节点的 "children": [...] 里会列出它的左右输入算子（如 TABLE_SCAN），这就是典型的树状组织。你得手动展开或用工具解析，不是点开就看见流程图。
-
EXPLAIN FORMAT=JSON必须加在SELECT前，不支持UPDATE/DELETE的 JSON 格式输出（MySQL 8.0+ 对 DML 仅支持传统表格格式） - 返回 JSON 中的
"query_block"和嵌套的"nested_loop"、"hash_join"等字段名，就是逻辑算子类型，对应优化器选择的连接策略 - 注意
"cost_info"下的"eval_cost"和"prefix_cost"，它们反映各子树的成本估算，是判断优化器“为什么选这个树”的关键依据
为什么 DESCRIBE 或普通 EXPLAIN 不显示树结构
因为 DESCRIBE（等价于 EXPLAIN）只输出扁平化表格，每行代表一个访问层（如驱动表、被驱动表），靠 id 和 select_type 暗示嵌套关系，但不显式建模父子连接。比如子查询的 id 更大，只是告诉你“先执行”，并不说明它作为哪个节点的 child 被挂载。
这种设计源于早期 MySQL 查询优化器的线性计划生成逻辑，直到 5.6 引入 JSON 格式才开始暴露更深层结构。
- 看到
type: DERIVED或select_type: SUBQUERY，只表示“有子查询”，但不知道它在整体计划中是 left/right input 还是 filter 条件节点 -
possible_keys和key列只告诉你用了哪个索引，不体现该索引扫描结果如何被下游算子消费（例如：是 join 的 build side？还是 group by 的输入？） - 如果你依赖 Navicat 或 DBeaver 的“可视化执行计划”功能，它们只是把
EXPLAIN表格按id排序后画线连接，属于启发式还原，不是真实树结构
真正接近逻辑树的操作：使用 optimizer_trace
想看优化器“怎么一步步推导出那棵树”，得打开 optimizer_trace。它记录优化器从语法解析 → 逻辑改写 → 索引选择 → 连接顺序穷举 → 成本比较 → 最终选定计划的全过程，比 EXPLAIN FORMAT=JSON 更底层。
启用后执行一次查询，再查 information_schema.OPTIMIZER_TRACE 表，就能拿到带缩进、分阶段的 trace 文本 —— 其中 "join_optimization" 和 "join_execution" 两节明确展示备选计划树和最终选定树的 JSON 描述。
- 必须显式开启：
SET SESSION optimizer_trace="enabled=on";，且SET SESSION optimizer_trace_max_mem_size=1048576;（避免截断） - trace 结果里
"chosen_plan"字段才是最终被选中的那棵逻辑树，而"attaching_conditions_to_tables"等节说明条件如何下推到各节点 - 注意 trace 不影响执行，但会轻微拖慢解析速度；生产环境慎用，查完记得
SET SESSION optimizer_trace="enabled=off";
容易忽略的关键点：树结构 ≠ 物理执行顺序
MySQL 的逻辑计划树描述的是“数据流依赖关系”，不是 CPU 上指令执行的时序。比如 HASH JOIN 节点的左 child（build side）必须完全读完才能启动右 child（probe side），但你在 EXPLAIN FORMAT=JSON 里看到的 "children" 数组顺序并不保证执行先后 —— 它只表示数据流向。
真正决定执行节奏的是算子类型和存储引擎行为：InnoDB 的 index dive 可能触发多次 B+ 树遍历，而 MRR（Multi-Range Read）会重排主键访问顺序。这些细节不会出现在逻辑树里，得结合 Extra 字段（如 Using index condition）和 SHOW PROFILE 观察。
所以别只盯着树形结构做优化；如果 rows 预估严重偏离实际，或者 Extra 出现 Using temporary，说明逻辑树再漂亮，物理执行也可能崩盘。
