订单列表慢查询排查：MySQL JSON 计划里的四类代价字段

线上订单列表突然变慢时，很多人第一眼只看 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 表，列表查询按用户ID和创建时间筛选：

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

传统EXPLAIN格式可以告诉你查询用了哪个索引，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行，实际每次循环却要扫出18000行，说明优化器对数据分布或条件选择性的判断已经失真。这个问题远比“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对照真实执行结果，索引优化的决策才能有完整的证据支撑。