Navicat的执行计划成本Cost值是如何计算的

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 的完整输出里找支撑项。