如果你经常使用 Navicat 查看执行计划，一定对那个 Cost 数字不陌生——一个孤零零的数值，有时是几位数，有时会超过百位。但很少有人仔细探究过：这个值到底是谁计算出来的？它真的能直接指导索引优化吗？先说结论：Navicat 本身不参与任何 Cost 计算，它只是忠实地把数据库引擎算好的结果展示给你看。简单来说，你看到的 Cost 数字，是 MySQL 或 Oracle 内部优化器“估算”出来的，Navicat 不过是那块显示屏幕。
Navicat 本身不计算 Cost 值，它只是展示 MySQL 或 Oracle 的执行计划结果
Navicat 是一个数据库客户端工具，并非查询优化器。它通过调用 explain（MySQL）或 explain plan（Oracle）获取执行计划，然后将数据库返回的 cost 字段原样呈现在「执行计划」窗口中。你看到的 cost 数值，完全由后端数据库引擎（如 MySQL 8.0+ 或 Oracle 12c+）内部估算得出，Navicat 不参与任何计算逻辑。换句话说，你把 SQL 提交给数据库，数据库自己算出一笔账，Navicat 再把这笔账念给你听——它既不知道这笔账是如何计算的，也没有能力替你修改账本。
MySQL 的 Cost 值是优化器估算的相对资源开销，单位没有实际物理含义
从 MySQL 5.7 开始，优化器采用了基于成本的模式（CBO）。这里的 cost 是一个归一化后的估算值，用于横向比较不同执行路径的优劣。它既不是毫秒，也不是 CPU 周期数，而是一个内部权重。具体由三部分组成：
read_cost：估算从磁盘或缓冲池读取数据页的成本（包含索引页和数据页）eval_cost：估算对读出的每一行进行条件判断、函数计算等 CPU 操作的成本- 总
cost=read_cost+eval_cost+ 其他子操作成本（如排序、临时表）
这个值严重依赖统计信息——如果表长期没有执行 ANALYZE TABLE，Cost 就相当于瞎猜。此外，参数如 innodb_page_size、optimizer_switch 也会影响最终数值。你可以在 MySQL 中执行 EXPLAIN FORMAT=JSON SELECT ...，在 JSON 输出的 "cost_info" 节点下看到明细；但 Navicat GUI 默认只显示汇总的 cost 列，不会展开这些细节。所以，千万不要把那个数字当成绝对的“速度指标”。
Oracle 的 Cost 值有明确公式，但 Navicat 不提供参数来源支持
Oracle 的公式倒是写得明明白白：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 默认不展示）
换句话说，Oracle 的 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 的完整输出中寻找。多往下翻几层，你才能看到 Cost 背后的“真实账本”。
