navicat 不计算 cost 值，仅原样展示 mysql 或 oracle 数据库优化器生成的执行计划中已计算的 cost；该值分别为 mysql 的归一化估算资源开销和 oracle 基于 i/o 与 cpu 的公式计算结果，但 navicat 不提供参数支持、统计上下文或明细分解。
navicat 本身不计算 cost 值，它只是显示 mysql 或 oracle 的执行计划结果
navicat 是一个数据库客户端工具，不是查询优化器。它调用 explain（mysql）或 explain plan（oracle）获取执行计划，并把数据库返回的 cost 字段原样展示在「执行计划」窗口里。你看到的 cost 数值，完全由后端数据库引擎（如 mysql 8.0+ 或 oracle 12c+）内部估算得出，navicat 不参与任何计算逻辑。
MySQL 的 Cost 值是优化器估算的相对资源开销，单位无实际物理意义
MySQL 5.7 起引入了基于成本的优化器（CBO），其 cost 是一个归一化后的估算值，用于横向比较不同执行路径的优劣。它不是毫秒、不是 CPU 周期数，只是一个内部权重：
-
read_cost：估算从磁盘或缓冲池读取数据页的成本（含索引页和数据页） -
eval_cost：估算对读出的每一行做条件判断、函数计算等 CPU 操作的成本 - 总
cost=read_cost+eval_cost+ 其他子操作成本（如排序、临时表） - 该值依赖统计信息（
ANALYZE TABLE更新）、配置参数（如innodb_page_size、optimizer_switch）
例如执行 EXPLAIN FORMAT=JSON SELECT ... 后，在 JSON 输出的 "cost_info" 节点下可看到明细；但 Navicat GUI 默认只显示汇总 cost 列，不展开。
Oracle 的 Cost 值有明确公式，但 Navicat 不提供参数来源支持
Oracle 的 Cost 计算公式为：Cost = (#SRds * sreadtim + #MRds * mreadtim + CPUCycles / cpuspeed) / sreadtim。其中关键参数（sreadtim、mreadtim、cpuspeed）来自系统统计视图（如 V$SYSTEM_PARAMETER、DBA_TAB_STATISTICS），需 DBA 权限查看。
Navicat 即使连接的是 Oracle，也仅能显示执行计划中已计算好的 COST 列（来自 PLAN_TABLE.COST），无法：
- 让你修改
db_file_multiblock_count或ioseektim等底层参数来验证公式 - 自动补全缺失的统计信息上下文（比如未收集直方图时，
effective_index_selectivity估算会严重失真） - 区分是 I/O 主导还是 CPU 主导的高 cost（需结合
IO_COST和CPU_COST单独列，而 Navicat 默认不展示）
真正影响 Cost 判断的，是你看不到的隐式前提
很多人盯着 Navicat 里那个 Cost 数字调索引，却忽略几个硬性前提：
- MySQL 的
cost估算严重依赖information_schema.STATISTICS中的CARDINALITY，如果表长期未ANALYZE，Cost 就是拍脑袋值 - Oracle 的 Cost 对
clustering_factor极敏感——同一个索引，clustering_factor接近表块数时 Cost 会飙升，但 Navicat 不显示该字段 - Navicat 执行
EXPLAIN时默认不带绑定变量值，而真实执行计划可能因变量值不同走完全不同路径（即“bind peeking”问题），此时 Cost 完全不可比
所以别直接信 Navicat 表格里那个 Cost 数字；它只是个参考标尺，真正的判断依据得回到 EXPLAIN FORMAT=JSON 或 DBMS_XPLAN.DISPLAY 的完整输出里找支撑项。
