MySQL EXPLAIN FORMAT=JSON 读取访问路径的操作清单

我第一次认真读 EXPLAIN FORMAT=JSON 时，最大的误区是从 query_cost 开始找答案。数字很醒目，却不能单独说明索引是否合理。更稳的读法是先找到每张表的访问节点，再把访问类型、候选索引、实际索引、估算行数和条件落点串起来看。

官方资料：MySQL 8.4 EXPLAIN Statement、EXPLAIN Output Format。

先确认输出版本与检查边界

最小命令就是：

EXPLAIN FORMAT=JSON
SELECT o.id, o.created_at
FROM orders AS o
WHERE o.customer_id = 42
  AND o.created_at >= '2026-09-01';

MySQL 8.4 支持两种 JSON 输出版本：默认的版本 1 保留传统 JSON 层级；把系统变量 explain_json_format_version 设为 2 后，输出会以访问路径为中心。团队脚本如果会解析字段，必须先固定或记录版本，不能把两套结构混用。

SELECT @@explain_json_format_version;
EXPLAIN FORMAT=JSON SELECT ...;

本文以常见的版本 1 字段名为主。它适合回答“优化器准备怎样访问数据”，但普通 EXPLAIN 不会执行查询，所以行数和成本是估算值，不是实测耗时。

先从根节点找到表访问路径

先展开 query_block。单表查询通常可以直接看到 table；连接查询常见 nested_loop 数组，每个元素对应一个表访问节点。我的习惯是先抄下表名和节点顺序，再读节点内部字段，避免把某个索引信息归到另一张表上。

遇到派生表、子查询、分组或排序时，不要只搜索第一个 table。应保持 JSON 层级，分别记录外层查询块、子查询块以及 grouping_operation、ordering_operation 等包装节点。层级本身就是“这个动作属于谁”的证据。

把访问类型和索引选择放在一起看

表节点里最值得先读的是以下字段：

一个可操作的判断是：possible_keys 有目标索引而 key 没选它，先查统计信息、选择性和成本；key 选中了联合索引但 used_key_parts 较短，再检查最左前缀、范围条件之后的列以及表达式是否与索引定义一致。不要只凭“索引存在”下结论。

把估算数字变成排查线索

rows_examined_per_scan 是每次扫描预计检查的行数，rows_produced_per_join 是当前节点在连接中预计产生的行数，filtered 表示条件过滤后预计保留的百分比。三者应放在同一个表节点内联读。

例如，预计扫描行数很大、filtered 又很低，通常说明大量数据在读取后才被条件淘汰。这不是自动等于“缺索引”，但值得继续检查条件能否进入索引、统计信息是否过旧、字段类型是否发生隐式转换。连接查询还要看这个估算是否在后续节点被放大。

cost_info 中常见 read_cost、eval_cost 和累计性质的 prefix_cost。这些值用于优化器内部比较候选计划，不是毫秒，也不适合跨机器、跨版本直接比较。最有价值的对比是在同一环境、同一统计信息背景下，对修改前后的候选计划做相对判断。

检查条件落点与额外操作

attached_condition 表示附着在当前表节点上的条件。它可以帮助确认谓词落在哪个节点，但不能只凭这一项断言条件是在存储引擎层还是服务器层完成。索引使用、索引条件下推和覆盖读取要结合相邻字段与官方输出说明判断。

• using_index 通常表示所需列可由索引提供，但仍要结合选择列与索引定义确认。
• using_filesort 表示排序不能直接由当前访问路径自然满足；它不等于写入磁盘，也不等于一定很慢。
• using_temporary_table 提示计划包含内部临时表相关操作，应结合分组、去重和排序结构检查。
• attached_subqueries、select_list_subqueries 等子结构要单独读取其查询块，避免漏掉重复执行风险。

我会把这些字段当作“下一步检查入口”，而不是红灯。计划中出现额外操作并不自动证明 SQL 有问题；关键是它处理多少数据，以及是否有更符合业务约束的索引或写法。

按节点记录证据，再决定修改动作

读取完后，可以把每个表节点压缩成一行记录：

表名 | access_type | key / used_key_parts | rows_examined_per_scan
filtered | attached_condition | using_index | using_filesort | prefix_cost

然后按证据决定动作：

1. 候选索引为空：确认条件列是否有可用索引，以及表达式、类型转换是否破坏匹配。
2. 有候选但未选择：检查选择性、统计信息、回表代价和索引宽度；必要时在测试环境执行 ANALYZE TABLE 后重看计划。
3. 联合索引只用前几列：检查最左前缀、等值与范围条件的排列。
4. 估算行数异常：比较表统计信息、数据分布和真实行数，避免只改 SQL 文本。
5. 排序或临时表处理数据过多：检查过滤是否能提前、排序列是否能与索引顺序协调。

修改后做反向验证

调优后的第一步不是宣布“命中索引”，而是重新保存同一条语句的 JSON 计划，逐项比较表节点：访问类型是否改变、used_key_parts 是否更符合条件、预计扫描与产出是否收敛、排序或临时表标记是否变化。

随后再补真实执行证据。MySQL 的 EXPLAIN ANALYZE 会实际运行支持的语句，并提供迭代器的估算与实际行数、时间和循环次数；在生产环境使用前要先评估语句副作用与负载。最终判断仍应结合延迟分布、扫描行数、锁等待和业务吞吐，不能把 JSON 成本值当作耗时。

最终操作清单

• 记录 MySQL 版本与 explain_json_format_version。
• 从 query_block 保持层级地定位所有表与子查询节点。
• 联读 access_type、possible_keys、key、used_key_parts。
• 同节点比较扫描行数、产出行数和 filtered。
• 检查 attached_condition、覆盖索引、排序和临时表标记。
• 只在同一环境中相对比较 cost_info。
• 修改后重新采集计划，并用真实执行数据确认收益。

相关问题

possible_keys 有索引，为什么 key 仍然为空？

possible_keys 只表示索引具备候选资格。优化器仍可能认为全表扫描成本更低，或者受统计信息、选择性、类型转换等因素影响而不采用它。

using_filesort 是否一定会落盘？

不一定。它表示排序不是直接按索引顺序取得，排序可以在内存或其他内部机制中完成，不能仅凭这个标记推断磁盘 I/O。

query_cost 可以换算成毫秒吗？

不能。它是优化器成本模型中的相对估算值，适合比较候选计划，不是墙钟时间。真实耗时要看实际执行和监控指标。