MySQL EXPLAIN FORMAT=JSON 读取 cost_info 成本信息

MySQL 的 EXPLAIN FORMAT=JSON 会把执行计划展开成层级对象，cost_info 就藏在查询块或具体表节点里。读取它的重点不是寻找一个越小越好的数字，而是把成本估算和访问方式、扫描行数、实际索引放在一起比较。

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

最实用的做法是先看查询级 query_cost，再进入每个表节点比较 read_cost、eval_cost、prefix_cost 与 data_read_per_join。这些数值是优化器的估算，不是一次真实执行的耗时。

先看懂 cost_info 在 JSON 计划中的位置

一个简单计划通常有两层成本信息：query_block.cost_info.query_cost 表示整个查询块的估算成本；table.cost_info 则贴近某个表或连接步骤。表节点旁边的 access_type、key、rows_examined_per_scan 和 rows_produced_per_join 是解释成本的上下文。

用一个可重复的查询读取成本字段

先用固定的表、条件和索引场景做对比，避免每次换查询导致数字没有可比性。示例只展示命令结构，不代表在本文环境中实际执行：

-- 用 JSON 格式查看优化器对查询的估算计划
EXPLAIN FORMAT=JSON
SELECT id, name
FROM customer
WHERE tenant_id = 7 AND status = 'active';

返回结果中，先定位 query_block，再查看它下面的 cost_info。如果查询包含连接或子查询，不要只看最外层数字，要沿着 nested_loop、query_block 等节点找到实际参与读取的表。

用 JSON_EXTRACT 提取并保存成本快照

MySQL 8.4 支持把 JSON 计划写入用户变量，再使用 JSON 函数读取字段。这样可以把优化前后的关键指标放在同一张对比表中：

-- 先保存计划，再提取索引和成本字段，便于前后对比
EXPLAIN FORMAT=JSON INTO @plan
SELECT id, name
FROM customer
WHERE tenant_id = 7 AND status = 'active';

-- JSON_EXTRACT 返回 JSON 值，保留路径便于复查原始计划
SELECT
  JSON_EXTRACT(@plan, '$.query_block.cost_info.query_cost') AS query_cost,
  JSON_EXTRACT(@plan, '$.query_block.table.key') AS chosen_key,
  JSON_EXTRACT(@plan, '$.query_block.table.access_type') AS access_type,
  JSON_EXTRACT(@plan, '$.query_block.table.cost_info.read_cost') AS read_cost,
  JSON_EXTRACT(@plan, '$.query_block.table.cost_info.eval_cost') AS eval_cost;

路径必须跟着实际 JSON 层级变化。连接查询的表节点可能位于数组中，不能机械套用单表路径；遇到路径为空，先回到完整计划确认节点名称和嵌套位置。

按成本变化判断优化方向

成本数字只适合在同一查询、相近统计信息和同一配置条件下做相对比较。排查时按下面顺序看：

1. 先看 access_type 和 key 是否从全表扫描转为更合适的索引访问；
2. 再看 rows_examined_per_scan 与 rows_produced_per_join，确认候选行是否真的减少；
3. 最后比较 query_cost、prefix_cost 和 data_read_per_join，判断改动影响了读取、条件计算还是连接前缀。

例如新增索引后 query_cost 变小，但 rows_examined_per_scan 没有明显下降，可能只是访问路径变化，不能直接宣布查询已经解决。还应检查数据分布、统计信息、参数值和真实执行耗时。

处理版本与估算边界

MySQL 8.4 默认仍可使用 JSON 输出格式的版本1，并提供基于访问路径的 JSON 版本2；文章中的 cost_info 示例对应常见的版本1层级。若团队切换了 explain_json_format_version，应先固定版本再比较快照，否则路径和字段组织可能发生变化。

还要区分估算和实测：EXPLAIN FORMAT=JSON 解释的是优化器如何计划执行；需要真实行数、循环次数和耗时，应使用适合当前版本的 EXPLAIN ANALYZE 输出，并把它作为第二层证据。不要把 query_cost 当作毫秒，也不要把一次估算直接当成生产性能结论。

常见问题

cost_info 为空是不是执行计划失效？不一定。先确认 JSON 节点层级、语句类型和版本，再看是否读取了错误路径；字段不存在不等于查询没有执行计划。

为什么 query_cost 变小，接口仍然变慢？因为它是优化器估算，不能覆盖锁等待、缓存命中、网络传输、并发竞争和真实数据分布。用实测指标与执行计划一起判断。