SQL查询代价估算基于I/O、CPU等资源折算的量化模型，由基础操作代价、统计信息驱动的规模估算和路径组合规则三部分构成，其准确性高度依赖统计信息的时效性与质量。
SQL查询代价估算是数据库优化器做出执行计划选择的核心依据，不是凭经验猜测，而是基于一套可量化的成本模型进行计算。这个模型把I/O、CPU、内存、网络等资源消耗统一折算为“代价单位”，再比较不同执行路径的总代价，选出最小的那个。
代价模型的三大基础组件
现代关系型数据库（如PostgreSQL、SQL Server、Oracle）的成本模型通常由三部分构成：
- 基础操作代价：单次扫描一页数据、比较一个字段、哈希一次键值等原子操作的预设开销。这些值通过基准测试校准，随硬件变化可调整。
- 统计信息驱动的规模估算：利用表行数、列直方图、NULL比例、多列相关性等统计信息，估算WHERE条件过滤后剩余行数、JOIN结果集大小、GROUP BY分组数等——这是误差最大也最关键的环节。
- 路径组合规则：定义嵌套循环JOIN、哈希JOIN、归并JOIN各自的代价公式；区分顺序扫描、索引扫描、索引仅扫描的I/O与CPU权重；考虑排序、物化、重分布等中间步骤的额外开销。
为什么估算常不准？统计信息是命门
代价估算偏差80%以上源于统计信息滞后或失真。例如：
- 表刚批量插入100万新数据，但ANALYZE没运行，优化器仍按旧行数估算，可能放弃本该高效的索引扫描；
- WHERE子句中两个高度相关的列（如country = 'CN' AND city = 'Shanghai'）被当作独立事件估算，导致选择性高估，误判索引有效性；
- 字符串前缀重复率高（如日志表中大量'ERROR: timeout'），直方图无法刻画分布尾部，导致LIKE 'ERROR%'谓词的过滤率严重误估。
看懂EXPLAIN输出里的Cost字段
以PostgreSQL为例，EXPLAIN (ANALYZE, COSTS ON)中每行的cost=100.00..2500.50 rows=1234 width=64含义是：
- 100.00：启动代价（start-up cost），即返回第一行前的预处理开销（如排序准备、索引定位）；
- 2500.50：总代价（total cost），包含启动代价+获取所有行的累计开销；
- rows=1234：优化器预测该节点输出行数，直接影响下游JOIN或SORT的代价计算；
- width=64：平均每行字节数，用于估算内存和网络传输成本。
注意：这些数值无绝对单位，只用于横向比较。实际执行时若Actual Rows远大于Rows，说明统计信息需更新或谓词建模有缺陷。
调优时真正该盯住的不是Cost数字，而是估算逻辑链
与其纠结“为什么这个计划cost是2500而不是2400”，不如逆向追踪：
- 该节点的rows是怎么算出来的？查pg_stats确认对应列的n_distinct、most_common_vals是否合理；
- 如果用了索引，index condition是否能被统计信息覆盖？检查是否存在表达式索引但未收集函数统计的情况；
- JOIN顺序是否因某张小表的行数误估而错配？用SET enable_hashjoin = off临时禁用某类JOIN验证假设；
- 是否触发了代价模型未充分建模的场景？如大结果集上的Window Function、JSONB深度遍历、全文检索rank计算——这些往往有隐式CPU惩罚但未显式计入cost。
