EXPLAIN FORMATTREE 深度解读看懂 MySQL 8.4 执行计划底层树状节点周三下午研发部的后厨又冒烟了。一位刚从单体架构转战高并发交易的研发小哥在群里贴了一张长达 80 行的 SQL神情焦急“大喜姐这条三表关联的订单详情查询在测试库上跑只要 5 毫秒怎么一上线直接卡死 8 秒我用经典的EXPLAIN看了表格里的type显示是refpossible_keys也命中了主键索引rows才预估了几十行根本看不出哪里慢啊”我把他的 SQL 扔进最新的 MySQL 8.4 终端输入EXPLAIN FORMATTREE。回车敲下的瞬间终端吐出了一棵缩进分明、层次严密的算子执行树。在树状节点的最深处赫然暴露了真相- Filter: (o.order_status PAID) (cost14205.20 rows4820)- Hash join (no condition) (cost9852.10 rows120000)优化器由于某个关联列的数据类型发生隐式字符集转换放弃了索引嵌套循环连接Nested Loop Join转而退化为昂贵的全量内存 Hash Join并触发了深度的过滤滞后很多开发者的认知仍然停留在 MySQL 5.7 时代那个简陋的平铺表格Tabular Formatid, select_type, table, type, possible_keys, key, rows, Extra...。这种扁平表格在面对复杂的嵌套子查询、现代迭代器模型以及 Hash Join 时完全无法体现真实的算子执行先后顺序与数据流向。MySQL 8.0 引入并作为 8.4 LTS 核心诊断武器的EXPLAIN FORMATTREE彻底撕下了传统黑盒的遮羞布让我们能以类似现代编译器 AST 的方式一针见血看懂执行器内部的每一处硬件级拉锯。一、 从表格到树状执行计划为什么经典 EXPLAIN 会“说谎”在 MySQL 5.7 时代传统的EXPLAIN表格输出是基于陈旧的“块级驱动Block Nested Loop”思维设计的。它存在三个致命盲区------------------------------------------------------------- | 传统表格 EXPLAIN 的误区: | | 行号 1: table A, type: ref | | 行号 2: table B, type: ref | | 行号 3: table C, type: ALL | ------------------------------------------------------------- * 致命缺陷无法看出到底是 (A JOIN B) 后再过滤 C还是 B 先过滤再与 A 连接 * 更加无法体现真实执行代价 (Cost) 在各个局部算子上的具体分布 ------------------------------------------------------------- | 现代 FORMATTREE 算子树: | | - Nested loop inner join (cost125.40 rows10) | | - Index lookup on A (cost12.20 rows1) | | - Filter: (C.status 1) (cost113.20 rows10) | | - Index lookup on C (cost15.00 rows50) | ------------------------------------------------------------- * 优势严格由内向外、自下而上阅读真实执行代价一览无余执行顺序全凭猜平铺表格中的行顺序在遇到子查询、CTE公用表表达式或半连接Semi-Join时并不完全等于物理执行的时序极易误导排查方向。算子开销黑盒化传统表格只给你一个总体的rows估算值你根本不知道整个查询中最耗费 CPU 的开销到底是在全表扫描、在临时表去重、还是在外部排序filesort上。现代物理执行器Volcano Iterator Model的解耦MySQL 8.0 完全重构了底层执行器采用面向对象的迭代器模型。传统的表格已经无法表达“每个迭代器节点的初始化成本、首行耗时与总体物化代价”。二、 FORMATTREE 语法树的阅读核心心法自底向上由内而外树状执行计划的排版规则极其规范。掌握其阅读技巧关键在于识别缩进层级Indentation Level核心黄金阅读准则缩进最深、嵌套在最里面的节点最先执行同一缩进层级的节点从上到下依序作为驱动方与被驱动方流转。看懂节点旁的三个关键度量指标cost优化器预估的物理计算代价基于磁盘 I/O 读取页数与 CPU 运算指令综合折算。rows该算子预计产出的有效数据行数。括号内的附加算子如(actual time0.045..1.230 rows50 loops1)如果搭配EXPLAIN ANALYZE使用前一个时间是产出第一行的耗时后一个时间是拉取全部行的耗时。三、 经典树状节点解剖与实操案例让我们来看一条线上真实的三表联合复杂查询及其对应的 TREE 执行计划EXPLAIN FORMATTREE SELECT c.customer_name, count(o.order_id) AS order_count, sum(oi.price * oi.quantity) AS total_spent FROM customers c JOIN orders o ON c.customer_id o.customer_id JOIN order_items oi ON o.order_id oi.order_id WHERE c.vip_level GOLD AND o.order_date 2026-09-01 GROUP BY c.customer_id, c.customer_name ORDER BY total_spent DESC LIMIT 10;MySQL 8.4 输出的树状计划深度解构- Limit: 10 row(s) (cost4582.10 rows10) - Sort: total_spent DESC, limit input to 10 row(s) (cost4582.10 rows10) - Table scan on temporary (cost4550.00 rows320) - Aggregate using temporary table (cost4550.00 rows320) - Nested loop inner join (cost4230.00 rows3200) - Nested loop inner join (cost1030.00 rows800) - Filter: (c.vip_level GOLD) (cost230.00 rows200) - Index range scan on customers using idx_vip_level over (vip_level GOLD) (cost230.00 rows200) - Filter: (o.order_date TIMESTAMP2026-09-01 00:00:00) (cost4.00 rows4) - Index lookup on o using idx_customer_id (customer_idc.customer_id) (cost4.00 rows4) - Index lookup on oi using idx_order_id (order_ido.order_id) (cost3.20 rows4)逐层“剥洋葱”式推导过程第一步最深层叶子节点Index range scan on customers using idx_vip_level。优化器首先利用索引范围扫描找出vip_level GOLD的 200 个黄金会员代价为 230.00。第二步第一层 Nested Loop Join以内层的 200 个用户为驱动表向orders表发起索引等值查找Index lookup on o using idx_customer_id同时附加过滤order_date 2026-09-01产出 800 条符合条件的订单。第三步第二层 Nested Loop Join以这 800 条订单为主语继续通过idx_order_id等值查找order_items表展开为 3200 条细分商品明细行。第四步内存临时表聚合Aggregate using temporary table。由于涉及多表非连续主键分组优化器开辟了一块内存临时表构建哈希聚合将 3200 行折叠为 320 行汇总记录。第五步外部排序与 Top-N 截断Sort: total_spent DESC。优化器使用快速选择Quick Select堆排序直接锁死前 10 行避免对全部 320 行做代价昂贵的全量深排序最终向上抛给客户端。整条链路每个算子的输入、输出、成本倾斜一目了然四、 识别高危节点的四大“警报信号”在阅读 TREE 计划时一旦在节点中扫出以下字眼往往就是慢查询的致命病灶------------------------------------------------------------- | TREE 执行计划四大危险信号 | ------------------------------------------------------------- | 1. Block Hash Join (没有索引可用大表在内存中暴力分块碰撞) | | 2. Table scan on temporary (临时表产生可能伴随内存溢出写盘)| | 3. Sort with filesort (无法利用索引顺序产生昂贵的物理磁盘排序)| | 4. Filter with high cost / rows mismatch (统计信息过时导致盲判)| -------------------------------------------------------------特别是在 MySQL 8.0 引入 Hash Join 之后当两张表关联列均没有索引或者存在隐式函数转换如WHERE LOWER(uid) o.uid树状图里会显式打印- Inner hash join (c.uid o.uid) (cost284000.00 rows500000)此时哪怕看到rows只有几十万其瞬间的 CPU 占用也会把单核打满必须立刻针对关联列补齐强类型索引。五、 进阶实战EXPLAIN ANALYZE 的终极度量在日常开发中建议将EXPLAIN FORMATTREE升级为EXPLAIN ANALYZE在测试库或只读副本上执行。它不仅打印静态推导的树状结构更会真正执行一次 SQL 并测量各节点的物理耗时EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id 8888;输出将带有真实的物理时钟- Index lookup on orders using idx_uid (user_id8888) (actual time0.034..0.042 rows3 loops1)actual time0.034该算子吐出第一条数据经过的物理毫秒数..0.042该算子吐出最后一条数据并收敛的物理毫秒数loops1该算子被外层循环迭代调用的总次数。如果某个节点的cost预估很小但actual time突增了上千毫秒说明底层表统计信息Histogram / Cardinality已经严重失真必须立刻执行ANALYZE TABLE重建直方图纠偏优化器的物理决策。