Navicat 不计算也不显示 Cost，仅展示数据库原生执行计划；MySQL 的 Cost 需 EXPLAIN FORMAT=JSON 查 cost_info；PostgreSQL 的 Total Cost 是抽象估算值，非毫秒；Oracle 需用 'ALL' 格式才显示 CPU_COST 和 IO_COST。
navicat 本身不显示 cost 数值，也不提供成本计算器——它只是把数据库原生的执行计划结果渲染出来。真正决定 cost 的是后端数据库（mysql/postgresql/oracle），而 navicat 只负责转发和展示。
MySQL 的 Cost 值在哪找？FORMAT=JSON 是唯一入口
MySQL 5.7+ 的优化器会计算 read_cost 和 eval_cost，但这些只出现在 EXPLAIN FORMAT=JSON 输出里，Navicat 默认的表格视图完全不显示它们。
- 必须手动写
EXPLAIN FORMAT=JSON SELECT ...，然后按F5运行（不是点“解释”按钮） - 结果是一大段 JSON，搜索
"cost_info"字段，里面会有"read_cost"、"eval_cost"、"prefix_cost" - 注意：
show warnings能看到优化器重写后的语句，但不会补全 Cost；EXPLAIN FORMAT=TRADITIONAL也压根不带 Cost 列 - Cost 单位无实际物理意义，只用于同一查询不同执行路径间的相对比较——比如嵌套循环 vs 条件推送下推的代价差
PostgreSQL 的 Total Cost 是什么？别把它当毫秒数
PostgreSQL 的执行计划第一行会显示 Total Cost，例如 Cost=100.00..200.00，但这不是执行时间，而是优化器基于统计信息估算的抽象开销。
- 前半部分（100.00）是启动成本（startup cost），后半部分（200.00）是总成本（total cost）
- 这个值由
seq_page_cost、random_page_cost、cpu_tuple_cost等 GUC 参数加权算出，和你机器的实际 I/O 性能强相关 - Navicat 默认发的是
EXPLAIN，不带ANALYZE；想验证估算是否靠谱，得手动改成EXPLAIN (ANALYZE, BUFFERS)看真实耗时与缓冲区读取页数 - 如果修改了
random_page_cost从默认 4 改成 1.1（SSD 场景），你会发现很多原本走索引的计划突然变成顺序扫描——Cost 模型变了，决策就变
Oracle 的 Cost 和 %CPU 到底怎么看？Navicat 自动补全有盲区
Oracle 的 Cost 是 CBO（Cost-Based Optimizer）输出的核心指标，但 Navicat 在调用 EXPLAIN PLAN FOR 后查 DBMS_XPLAN.DISPLAY 时，默认只返回基础字段，CPU_COST、IO_COST、%CPU 这些列需要显式要求。
- 必须在 Navicat 查询窗口中执行完整语句：
EXPLAIN PLAN FOR SELECT ...; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'ALL')); -
'ALL'格式才能带出CPU_COST和IO_COST；%CPU = CPU_COST / (CPU_COST + IO_COST)，反映该步骤对 CPU 资源的相对消耗比重 - Navicat 不会自动帮你加
'ALL'，也不会提示缺失字段——你看到的 Plan 表格里没有这些列，不代表数据库没算，只是没选出来 - 10g 和 11g+ 的 Cost 定义差异很大：11g 明确区分了 CPU 和 I/O 成本，而 10g 的
COST是个黑箱总和，没法拆解
Cost 数值本身不解决性能问题，但它暴露了优化器的“判断依据”。真正容易被忽略的是：你改了一个索引、删了一行 WHERE 条件、甚至只是 ANALYZE 了一张表，都可能让 Cost 突然翻倍或归零——因为底层统计信息变了。别只盯着 type 和 key，先确认你看到的 Cost，是不是数据库当前真实启用的成本模型算出来的。
