PostgreSQL成本模型通过启动成本、总成本及I/O与CPU权重估算执行计划优劣，依赖统计信息与可调参数（如seq_page_cost、random_page_cost）反映硬件特性，结合表扫描、索引扫描等成本计算方式，指导查询优化。
PostgreSQL优化器在生成执行计划时，会通过成本估算来比较不同执行路径的优劣，从而选择理论上执行最快的一条路径。这个过程依赖于一个称为“成本模型”的机制。理解该模型有助于我们写出更高效的SQL，也能帮助DBA调优查询性能。
成本模型的基本组成
PostgreSQL的成本模型将执行计划的总成本分为三部分：
- 启动成本（Startup Cost）：在开始返回第一行数据之前所需的成本，比如排序、物化等操作的开销。
- 总成本（Total Cost）：从开始执行到返回所有结果的预估总成本。
- I/O与CPU成本权重：模型中对磁盘I/O和CPU计算分别赋予不同的权重，默认情况下：
这些权重由以下参数控制：
- seq_page_cost：顺序读取一页的I/O成本，默认为1.0
- random_page_cost：随机读取一页的I/O成本，默认为4.0（SSD场景建议调低）
- cpu_tuple_cost：处理每一行元组的CPU成本，默认0.01
- cpu_index_tuple_cost：处理每个索引项的CPU成本，默认0.005
- cpu_operator_cost：执行一次操作（如比较）的CPU成本，默认0.0025
- parallel_setup_cost：启动并行工作进程的开销
- parallel_tuple_cost：并行执行中传输每行数据的成本
这些参数可在postgresql.conf中调整，也可通过SET命令临时修改，用于适应实际硬件环境（如使用SSD时降低random_page_cost）。
如何估算表扫描成本
全表扫描（Sequential Scan）的成本计算方式如下：
启动成本 = 0 I/O成本 = seq_page_cost × 表的页面数（relpages） CPU成本 = cpu_tuple_cost × 表的元组数（reltuples） 总成本 = I/O成本 + CPU成本
例如，一张表有10,000个数据页，100,000行记录：
- I/O成本 = 1.0 × 10000 = 10000
- CPU成本 = 0.01 × 100000 = 1000
- 总成本 ≈ 11000
注意：实际还会加上轻微的启动成本和函数操作开销。
索引扫描的成本估算
索引扫描（Index Scan）的成本更为复杂，主要包括：
- 索引访问I/O成本：依据索引层级和需读取的索引页数量
- 回表（Heap Fetch）成本：根据命中行数读取主表数据页
- 索引项处理的CPU成本
以B-tree索引为例，其成本大致为：
启动成本 = 索引定位开销（一般较小） I/O成本 = random_page_cost × 索引页访问数 + random_page_cost × 预估需回表的数据页数 CPU成本 = cpu_index_tuple_cost × 扫描的索引项数 + cpu_tuple_cost × 返回的元组数
如果查询选择性高（返回大量数据），优化器可能认为全表扫描更便宜；反之，选择性低时索引扫描更优。
PostgreSQL还支持“位图扫描（Bitmap Scan）”，适用于多个索引组合的情况。它先用索引构建一个位图标记匹配的TID，再统一读取数据页，减少随机I/O次数。
统计信息的作用
成本估算高度依赖系统统计信息，主要来自：
-
pg_class.reltuples和relpages：表的行数和页面数 -
pg_stats：列的唯一值数量、最常见值、频率直方图等 -
ANALYZE命令收集的统计信息直接影响选择率估算
若统计信息不准确（如大批次插入后未analyze），可能导致成本估算偏差，进而选择错误的执行计划。
查看执行计划中的成本
使用EXPLAIN可查看优化器估算的成本：
EXPLAIN SELECT * FROM users WHERE id = 1;
输出示例：
Index Scan using users_pkey on users (cost=0.43..8.45 rows=1 width=204)
其中：
- 0.43 是启动成本
- 8.45 是总成本
- rows=1 是预估返回行数
- width=204 是预估每行平均字节数
结合EXPLAIN ANALYZE还能看到实际执行时间，用于对比估算是否准确。
基本上就这些。理解PostgreSQL的成本模型，关键是掌握I/O与CPU的权衡、统计信息的影响以及硬件参数的适配。不复杂但容易忽略细节。
