MySQL EXPLAIN FORMAT=JSON 怎么读：cost_info、rows_examined_per_scan 与索引选择

排查订单列表变慢时，先别急着把所有字段都塞进联合索引。对同一条查询分别运行普通 EXPLAIN 和 EXPLAIN FORMAT=JSON，真正有用的是把访问路径、估算行数和成本字段串起来看：cost_info 说明优化器怎样估算代价，rows_examined_per_scan 则帮助你判断一次扫描到底要读多少行。它们不能单独替代执行验证，却能解释 MySQL 为什么选了当前索引。

阅读 JSON 执行计划的最短路径是：先找 table.access_type 和 key，再核对 rows_examined_per_scan、filtered 与 cost_info，最后用实际数据分布验证估算是否可信。

先把一条订单查询固定下来

示例表是 orders，查询只取最近 30 天、指定用户的已支付订单。测试时要固定绑定变量、排序和数据快照，否则每次计划变化都可能来自参数或统计信息，而不是索引本身。

EXPLAIN FORMAT=JSON
SELECT id, paid_at, total_amount
FROM orders
WHERE user_id = 1024
  AND status = 'paid'
  AND paid_at >= '2026-08-01'
ORDER BY paid_at DESC
LIMIT 20;

普通 EXPLAIN 适合快速扫一眼；JSON 版本会把表访问、条件过滤和成本拆成嵌套对象。本文只讨论估算计划，不把 cost_info 当成真实秒数。

cost_info 和 rows_examined_per_scan 分别回答什么

在 JSON 中定位 query_block.nested_loop[0].table，通常能看到 access_type、possible_keys、key、rows_examined_per_scan 和 filtered。rows_examined_per_scan 是一次访问路径预估要检查的行数，filtered 是条件筛选后的百分比估算。两者放在一起，才能看出索引把候选集合缩小了多少。

cost_info 常见于 read_cost、eval_cost 和 prefix_cost 等字段。它服务于优化器内部的方案比较：扫描更多候选行通常会抬高读取成本，但成本不是墙上时钟，也不等同于慢查询日志中的耗时。

图中从 orders 到 rows_examined_per_scan 再到 filtered 的链路，正对应这个判断：索引先缩小扫描范围，剩余条件再继续过滤。若估算行数很大而过滤比例很低，才值得继续追查索引前缀和统计信息。

沿着 key 和索引条件核对选择结果

看到 key 后，回到表结构确认它覆盖了哪些列，并区分“用于定位”的条件和“取到候选后再过滤”的条件。比如 idx_orders_user_status_paid_at 若按 user_id, status, paid_at 建立，查询里的等值条件先收缩范围，时间条件再帮助定位排序区间；但这不等于每个条件都会显示成独立的 JSON 节点。

可以用下面的检查顺序把计划读完：

1. 先看 access_type，确认是按索引查找、范围扫描还是全表扫描。
2. 再看 key 和 possible_keys，确认优化器实际选了谁、候选是谁。
3. 接着看 rows_examined_per_scan 与 filtered，估算候选集和过滤损耗。
4. 最后看 cost_info，理解方案比较方向，不把它当成实际耗时。

如果 key 为空，先不要强制 FORCE INDEX。低基数状态列、结果集本来就很小、统计信息过期，都会让全表或另一条路径在估算上更便宜。先记录计划，再用代表性参数做实际执行检查。

三个容易把 JSON 计划读错的地方

把 cost_info 当成毫秒数

成本字段是优化器的相对估算。它可以帮助比较两个候选路径，但不能直接回答“这条 SQL 是 8 毫秒还是 80 毫秒”。真实耗时应结合慢查询日志或受控环境中的执行观察。

只看 rows_examined_per_scan，不看 filtered

扫描 1000 行并留下 900 行，和扫描 1000 行只留下 10 行，优化方向完全不同。前者可能是条件选择性低，后者可能是索引没有把过滤条件前置。

看到全表扫描就立刻加索引

MySQL 选择计划时会考虑访问成本、数据量和统计信息。先确认查询参数具有代表性，再检查 ANALYZE TABLE orders 后计划是否变化；不要在生产高峰期直接用强制索引覆盖所有参数。

用同一组参数做一次反向验证

把原始 SQL、参数、表统计信息和 JSON 计划一并保存。新增或调整索引后重新运行同一条 EXPLAIN FORMAT=JSON，重点对比 key、rows_examined_per_scan、filtered 和 prefix_cost。如果估算明显改善但实际请求仍慢，下一层要检查回表、排序、锁等待或网络传输，不要继续只盯着 JSON 成本。

相关问题

rows_examined_per_scan 越小越好吗？

通常更有利，但不是唯一目标。还要看结果行数、排序、回表成本，以及这个估算是否贴近真实数据分布。

EXPLAIN FORMAT=JSON 能看到真实执行耗时吗？

普通 EXPLAIN FORMAT=JSON 主要描述估算计划。需要实际执行信息时，应使用适合当前环境的执行验证手段，并控制参数、数据量和副作用。

什么时候该更新统计信息？

当数据分布发生明显变化、计划突然切换，或估算行数与实际观察长期偏离时，可以在维护窗口评估 ANALYZE TABLE，并在同一参数下复查计划。

小结

读 MySQL JSON 计划不要从某一个醒目的数字开始，而要顺着 key、rows_examined_per_scan、filtered 和 cost_info 还原访问路径。这样既能知道索引有没有缩小候选集，也能避免把优化器估算误当成实际性能结论。