MySQL EXPLAIN FORMAT=JSON 怎么查看嵌套循环成本

看到 MySQL 的 EXPLAIN FORMAT=JSON 输出时，最容易迷路的是一串嵌套对象：到底哪张表是外层，哪一层把行数和成本放大了？读法可以固定下来：先进入 query_block.nested_loop，按表的层级看 rows_examined_per_scan 与 rows_produced_per_join，再用每层 cost_info.prefix_cost 对照累计估算。它们都是优化器估算，不是已经发生的耗时。

官方文档：https://dev.mysql.com/doc/refman/8.4/en/explain.html

先看 nested_loop 的位置，再读每一层成本

假设有一条订单查询：先筛出华东客户，再按客户编号连接订单，并限制订单日期。先对原查询加上 JSON 格式，不要先凭 JOIN 书写顺序猜执行顺序：

-- 查看优化器为这条 JOIN 选择的 JSON 计划
EXPLAIN FORMAT=JSON
SELECT o.id, c.name
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
WHERE c.region = '华东'
  AND o.created_at >= '2026-09-01';

在返回值中找到 query_block，再找它下面的 nested_loop 数组。数组元素通常各自包含一个 table 对象，里面能看到 table_name、access_type、key、行数估算和 cost_info。它表达的是计划结构与优化器判断，不是逐行记录的运行日志。

rows 两个字段要分清：单次访问和连接后规模

rows_examined_per_scan 表示访问当前表的一次扫描估算；内层表在嵌套循环中可能被外层每个候选行反复访问。rows_produced_per_join 则是把当前表加入前面连接后，优化器估算会继续传给下一层的行数。两者不相等并不奇怪。

例如外层客户估算 120 行，内层订单每次按索引检查 8 行，那么内层的连接规模可能接近 120 × 8，再叠加日期条件过滤。这里的乘法只是帮助理解字段关系，不能替代计划中的实际估算。

用 prefix_cost 定位放大的连接分支

每个表对象的 cost_info 通常会拆出 read_cost 和 eval_cost，而 prefix_cost 可以当作“处理到当前连接前缀”的累计估算。读 JSON 时不要只盯着最后一个数字：看哪一层从外层前缀到内层前缀出现明显跃升，再回到那张表的 access_type、实际选择的 key 和连接条件。

{
  "nested_loop": [
    {"table": {"table_name": "c", "access_type": "ref", "rows_examined_per_scan": 120,
      "rows_produced_per_join": 120,
      "cost_info": {"read_cost": "...", "eval_cost": "...", "prefix_cost": "..."}}},
    {"table": {"table_name": "o", "access_type": "ref", "rows_examined_per_scan": 8,
      "rows_produced_per_join": 480,
      "cost_info": {"read_cost": "...", "eval_cost": "...", "prefix_cost": "..."}}}
  ]
}

上面是字段位置示意，不是某次数据库运行结果。若内层 rows_produced_per_join 远大于预期，先确认连接列是否命中合适索引、统计信息是否陈旧、过滤条件是否能在更早的层生效；不要只因为 prefix_cost 变大就盲目加索引。

估算成本和真实耗时不是一回事

EXPLAIN FORMAT=JSON 适合回答“优化器预计怎样连接、哪里可能放大”；它不会告诉你这次请求实际用了多少毫秒、循环了多少次。需要运行时证据时，使用 MySQL 支持的树形分析：

-- 只读查询的实际执行信息使用 TREE 格式，便于对照 loops 和 actual time
EXPLAIN ANALYZE FORMAT=TREE
SELECT o.id, c.name
FROM customers AS c
JOIN orders AS o ON o.customer_id = c.id
WHERE c.region = '华东'
  AND o.created_at >= '2026-09-01';

排查时可以按“计划结构 → 行数估算 → 成本跃升 → 实际 loops/时间”的顺序记录。若估算和实际差异很大，再检查统计信息与数据分布；若实际内层 loops 很高，才有必要进一步调整连接条件、索引或查询形状。

常见问题

为什么 nested_loop 数组顺序不等于 SQL 里的表顺序？

优化器会选择它认为成本更低的连接顺序，JSON 数组反映计划结构。要强制测试书写顺序，可以用 STRAIGHT_JOIN 做对照，但不要把对照计划直接当成长期方案。

只看 query_cost 能判断哪张表慢吗？

不能。query_cost 是整条计划的估算汇总，定位问题要下钻到每个 table.cost_info，同时对照行数、索引和实际分析结果。

记住一句话：nested_loop 负责告诉你连接层级，两个 rows 字段告诉你规模如何变化，prefix_cost 帮你找到累计成本跃升的位置；真实性能结论必须由运行时分析补上。