MySQL 8.4 EXPLAIN FORMAT=JSON 怎么看 cost_info：估算偏差与索引决策

线上订单列表突然变慢时，很多人第一眼只看 EXPLAIN 里的 rows 和 key。如果两个候选索引都“能用”，真正帮助优化器做取舍的是成本估算。MySQL 8.4 的 EXPLAIN FORMAT=JSON 会把这些信息放进 cost_info，但它表示优化器的相对估算，不是接口耗时的毫秒数。

最实用的判断顺序是：先看 access_type、key 和估算行数，再看 query_cost 以及表级的 read_cost、eval_cost；最后用 EXPLAIN ANALYZE 对照真实行数和时间。只盯着一个更小的 cost 数字就改索引，容易把问题带偏。

cost_info 到底回答什么问题

假设有一张 orders 表，列表按用户和创建时间筛选：

SELECT id, status, created_at
FROM orders
WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

传统格式可以告诉你使用了哪个索引，JSON 格式则把优化器的判断拆得更细。一个简化后的结构大致如下：

{
  "table_name": "orders",
  "access_type": "range",
  "key": "idx_orders_user_status_created",
  "rows_examined_per_scan": 240,
  "rows_produced_per_join": 24,
  "filtered": "10.00",
  "cost_info": {
    "read_cost": "31.20",
    "eval_cost": "2.40",
    "prefix_cost": "33.60",
    "data_read_per_join": "18K"
  }
}

这里的数字用于比较不同的执行计划，不能直接对应成“读取 31.2 毫秒”或“评估 2.4 毫秒”。硬件配置、缓冲池命中率、并发负载和 I/O 特性都会改变真实耗时，但不会改变这段 JSON 输出的本身含义。

四个字段怎么连起来看

实际排查时，更建议先确认“估算行数有没有偏差离谱”，再讨论“哪个 cost 更低”。如果 rows_examined_per_scan 是 20 万，而实际结果只返回 20 行，那成本比较就已经建立在不可靠的基线上；此时应该先检查统计信息、数据分布和谓词写法。

用同一条 SQL 比较候选索引

先保存一份原始计划，再用 USE INDEX 临时观察另一条执行路径。不要一上来就写永久的 FORCE INDEX：

EXPLAIN FORMAT=JSON
SELECT id, status, created_at
FROM orders USE INDEX (idx_orders_user_created)
WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

对比时至少记录这五项：access_type、实际使用的 key、扫描估算行数、返回估算行数和 query_cost。如果一个计划 cost 更低，却需要大量回表，不能只看顶层数字；还要检查 data_read_per_join 和排序、过滤是否落在索引之后。

EXPLAIN ANALYZE 才能揭开估算偏差

EXPLAIN FORMAT=JSON 是“执行前的计划”，EXPLAIN ANALYZE 会实际执行语句并给出真实行数、循环次数和耗时。MySQL 8.4 中它使用 TREE 格式，适合验证 JSON 计划里最可疑的节点。

EXPLAIN ANALYZE
SELECT id, status, created_at
FROM orders
WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

如果估算返回 24 行，实际每次循环却产生 18,000 行，说明优化器对数据分布或条件选择性的判断失真。这个结果比“query_cost 从 33.6 变成 28.1”更值得优先处理。生产环境执行前要确认语句只读、数据量和锁影响可接受；长查询不要直接在高峰期运行。

估算偏差大时先查三件事

统计信息是否跟不上数据变化

大量导入、删除或状态集中变化后，旧统计信息可能让行数估算失真。先在低峰期更新相关表的统计信息，再重复同一份 EXPLAIN；不要把更新统计信息和新增索引混在一次实验里。

谓词是否破坏了可用的选择性

对索引列做函数包裹、隐式类型转换，或者把低选择性的状态列放在错误的索引顺序，都可能让计划扫描更多记录。把 SQL 改成可利用索引的形式后，再用 JSON 计划确认 key 和 access_type 是否真的变化。

测试参数是否代表真实用户

用户 ID 为 42 的计划，不一定代表活跃大客户或冷门账户。至少挑选小结果集、大结果集和数据分布中间值各测一次；如果只有某个参数异常，优先考虑数据倾斜和参数敏感性，而不是立即固定一个索引。

相关问题

query_cost 越小，SQL 就一定越快吗？

不一定。它是优化器成本模型里的估算值，适合在相同环境和相近数据分布下比较计划，不能替代实际耗时。

为什么 JSON 里的 rows 和实际返回行数差很多？

常见原因是统计信息过期、数据分布倾斜、条件选择性估算不准或谓词写法让索引收益下降。用 EXPLAIN ANALYZE 先定位偏差最大的节点。

可以直接用 FORCE INDEX 修复吗？

它更像临时诊断工具。数据量和分布会变化，永久强制某条索引可能让未来的计划更差；先验证索引设计与统计信息，再决定是否保留提示。

EXPLAIN ANALYZE 会修改数据吗？

它会实际执行语句，因此只对明确的只读查询使用。涉及 UPDATE、DELETE 或高成本查询时，先在副本或受控环境验证。

把 cost 当作线索，而不是结论

MySQL 8.4 的 cost_info 很适合解释“优化器为什么偏向这条路径”，但它不会替你完成性能验收。先核对访问类型和估算行数，再比较成本，最后用 EXPLAIN ANALYZE 对照真实执行结果，索引决策才有完整证据链。