MySQL 5.7 中标准 EXPLAIN 不显示成本是因为其仅输出执行计划结构信息，而 query_cost 作为优化器内部估算值仅在 EXPLAIN FORMAT=JSON 中提供，单位为抽象成本单位，用于横向比较而非换算实际耗时。
MySQL 5.7 中无法直接通过标准 EXPLAIN 查看真实成本，必须用 EXPLAIN FORMAT=JSON 才能拿到 query_cost 字段。
为什么普通 EXPLAIN 不显示成本？
标准 EXPLAIN（即表格格式）只输出执行计划的结构信息，如 type、key、rows 等，但不包含优化器计算出的总代价。MySQL 的成本模型是内部决策依据，不会在默认输出中暴露。
成本值（query_cost）只在 JSON 格式中提供，且从 MySQL 5.7 开始支持该功能——不是所有旧版本都默认启用，但 5.7.7+ 均可用。
-
EXPLAIN SELECT ...→ 只有估算行数、索引选择等，无成本数字 -
EXPLAIN FORMAT=JSON SELECT ...→ 返回 JSON 对象，含"query_cost": "X.XX"
EXPLAIN FORMAT=JSON 中 cost_info 的实际含义
query_cost 是 Server 层 + Engine 层的综合估算值，单位是“抽象成本单位”，不可直接换算为毫秒，但可用于横向比较不同写法的相对开销。
示例返回片段：
{
"query_block": {
"select_id": 1,
"cost_info": {
"query_cost": "55.61"
},
"table": {
"table_name": "orders",
"access_type": "range",
"key": "idx_status_created",
"rows_examined_per_scan": 39,
"cost_info": {
"read_cost": "55.60",
"eval_cost": "0.01"
}
}
}
}
关键点：
-
query_cost=read_cost+eval_cost，前者主要反映 I/O（页读取），后者反映 CPU（行过滤、计算） - 同一查询改写后
query_cost下降 30%，通常意味着性能提升可期 -
read_cost高而eval_cost低，说明瓶颈在索引扫描范围大；反之则可能是WHERE条件过滤效率差
容易被忽略的兼容性与配置陷阱
即使用了 FORMAT=JSON，也可能看不到 cost_info，常见原因：
- MySQL 5.7.6 之前版本不支持
FORMAT=JSON，需确认版本：SELECT VERSION(); - 用户没有
PROCESS权限时，EXPLAIN FORMAT=JSON会静默省略cost_info字段（不会报错） - 某些云厂商 RDS 默认关闭了优化器成本表（
mysql.server_cost、mysql.engine_cost），导致成本估算失真，但query_cost仍会显示（基于默认参数） -
query_cost是预估值，不代表真实耗时；若发现预估rows和实际扫描量偏差极大（比如rows=100但实际扫了 10 万行），说明统计信息过期，需ANALYZE TABLE
真正影响判断的，不是单次 query_cost 数字，而是不同写法之间的成本差值是否显著——尤其当 read_cost 占比超过 95% 时，优先优化索引覆盖或减少扫描范围，比调 eval_cost 相关参数更有效。
