PostgreSQL优化器在生成执行计划时，会对每条可能的访问路径计算一个总代价，代价由I/O和CPU两部分组成。I/O代价主要由seq_page_cost和random_page_cost控制，CPU代价则分解到cpu_tuple_cost、cpu_index_tuple_cost、cpu_operator_cost等参数中。很多数据库管理员在遇到查询计划不理想时，首先调整的是shared_buffers或work_mem，却忽略了这些成本参数。实际上，cpu_tuple_cost每处理一行元组就会计入一次，如果它的值偏高，优化器可能倾向于减少返回行数多的路径，反而选错索引连接顺序。本文将围绕这几个参数展开，说明它们的作用、修改方式以及调优时需要注意的边界。
一、成本参数在优化器中的角色
PostgreSQL采用基于成本的优化器（CBO），成本单位是一个抽象数值，并不直接等于毫秒或磁盘读写次数。优化器计算总代价时会累加启动代价和运行代价，公式大致为：总代价 = 启动代价 + 行数 × 单行处理代价 + 页数 × 单页读取代价。其中单行处理代价主要由cpu_tuple_cost等参数决定，单页读取代价由seq_page_cost与random_page_cost决定。如果单行处理代价被设置得过大，那么返回大量行的全表扫描或索引扫描就会被评估得非常昂贵，从而让优化器选择其他可能更差的路径。
举例来说，一条SQL需要扫描500万行数据，如果cpu_tuple_cost从默认的0.01提高到0.1，仅行处理代价就会增加450000个单位，足以让优化器放弃某个扫描路径。实际硬件CPU计算能力在不断变化，而PostgreSQL默认参数长期保持固定，这就造成一种偏差：在磁盘速度很快、CPU相对较慢的环境里，默认值可能高估I/O低估CPU，反之亦然。理解这一点后，才能针对性地修改参数，而不是盲目照搬某篇配置文章。
另一个容易忽略的现象是成本参数之间的相对比例比绝对值更关键。例如random_page_cost与seq_page_cost的比例会决定优化器对索引扫描的偏好，cpu_tuple_cost与random_page_cost的比例则会影响行处理代价在整体代价中的权重。单独修改某一个参数可能导致执行计划剧烈变化，所以调优时应把这些参数放在一起观察。
二、重点CPU成本参数详解
PostgreSQL中与CPU相关的成本参数主要有三个：cpu_tuple_cost、cpu_index_tuple_cost和cpu_operator_cost。cpu_tuple_cost表示优化器处理一行普通元组时消耗的CPU代价，默认值为0.01。它适用于顺序扫描、索引扫描以及各种连接运算中每一行数据的处理。cpu_index_tuple_cost表示处理一行索引元组时的CPU代价，默认值是0.005，通常比cpu_tuple_cost低，因为索引行一般更短，且不需要展开完整的堆元组。cpu_operator_cost表示执行一次WHERE条件、JOIN条件或函数调用等操作符的代价，默认值为0.0025，这个参数会影响复杂表达式较多场景下的计划选择。
除了这三个之外，还有parallel_setup_cost和parallel_tuple_cost两个并行相关参数。parallel_setup_cost默认1000，表示启动并行工作进程的固定代价；parallel_tuple_cost默认0.1，表示将一行数据从并行工作进程传递到主进程的代价。虽然它们不是直接的CPU行处理参数，但在评估并行计划时，优化器也会将并行相关的CPU通信代价计入，因此修改CPU成本参数时也需要一并考虑。
可以通过下面的SQL查询当前数据库的默认值：
SHOW cpu_tuple_cost;
SHOW cpu_index_tuple_cost;
SHOW cpu_operator_cost;
SELECT name, setting, unit FROM pg_settings WHERE name IN ('cpu_tuple_cost','cpu_index_tuple_cost','cpu_operator_cost');
上述查询返回的setting列就是当前生效值。注意这些参数属于用户可修改的配置参数，可以在会话级或全局级进行调整。若想看某个表上执行计划中的行代价分解，可以使用EXPLAIN语句，输出中的cost字段里已经包含了这些参数的计算结果。
三、修改成本参数的操作步骤
修改全局参数最常用的方式是编辑postgresql.conf文件，或者在数据库实例运行期间通过ALTER SYSTEM命令写入。例如希望把cpu_tuple_cost调整为0.03，把cpu_index_tuple_cost调整为0.01，可以在psql中执行：
ALTER SYSTEM SET cpu_tuple_cost = 0.03; ALTER SYSTEM SET cpu_index_tuple_cost = 0.01; SELECT pg_reload_conf();
ALTER SYSTEM会把配置写入postgresql.auto.conf文件，该文件在postgresql.conf之后被加载，因此不必直接修改主配置文件。pg_reload_conf()用于让数据库重新加载配置文件，但有些参数需要重启实例才完全生效，这些成本参数属于sighup级别，执行reload即可在后续新会话中生效。对于已经存在的会话，可以使用SET命令临时修改：
SET cpu_tuple_cost = 0.03; SHOW cpu_tuple_cost;
使用会话级SET的好处是不会影响其他连接，便于在单个窗口中比对执行计划。修改后可以立即用EXPLAIN查看代价变化，例如：
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE customer_id = 100 AND order_date > '2024-01-01';
在执行EXPLAIN时，如果加上ANALYZE选项，数据库会真正执行该语句并返回实际行数和执行时间，此时成本参数只影响计划选择，不影响输出结果。需要特别留意，ANALYZE会真正执行SQL，对写入语句不要随便加ANALYZE。
调整全局参数后，建议在测试环境先用EXPLAIN对比多个典型SQL的执行计划变化，再决定是否应用到生产。尤其在修改random_page_cost和cpu_tuple_cost的时候，最好结合pgbench或业务SQL进行压测，观察延迟和吞吐量是否真的改善。
四、调整策略与常见误区
一个常见误区是把cpu_tuple_cost设置得很低，认为这样可以让优化器更愿意处理大量行。实际上，行处理代价过低会让优化器低估全表扫描和大量行返回的代价，可能放弃索引扫描，导致实际执行时出现大量随机I/O。反之，把cpu_tuple_cost设置得很高，会让优化器过度偏好索引扫描或嵌套循环连接，在有些场景下这种偏好反而增加随机读。
另一个需要避免的做法是照搬聚合文章给出的参数组合，例如固定把random_page_cost改为1.1，把cpu_tuple_cost改为0.03。不同硬件和负载下，最优值差异很大。对于NVMe固态盘，random_page_cost可以接近1.0，但CPU参数需要根据机器单核计算能力调整。一般原则是：如果机器CPU算力较弱但磁盘速度较快，可以适当提高cpu_tuple_cost等CPU参数，让优化器更偏向减少行处理；如果CPU算力较强而磁盘随机读较慢，则降低CPU参数或维持默认，让优化器更关注I/O代价。
最后要强调，成本参数修改后必须验证执行计划是否稳定。可以通过pg_stat_statements收集高频查询，观察耗时和计划变化。如果某个SQL的代价估算变得很低但实际执行变慢，说明参数取值偏离了实际硬件。此时应回退到原始值，而不是继续叠加更多参数调整。调优的终点是让成本模型尽量贴近真实开销，而不是让某个SQL的代价数字变好看。
PostgreSQLcpu_tuple_cost成本参数修改时间：2026-09-23 08:07:43