PostgreSQL的查询优化器基于代价模型选择执行计划，其中I/O代价占据了主导地位。random_page_cost和seq_page_cost分别代表读取一个随机数据页和一个顺序数据页的相对成本，默认值通常为4和1。这个4:1的比例源自传统机械硬盘的物理特性：随机读取需要磁头寻道和盘片旋转，延迟通常在10毫秒以上，而顺序读取的寻道开销几乎可以忽略。然而，现代存储介质发生了巨大变化，继续使用默认值会让优化器产生错误判断，导致本该走索引的查询被错误地规划为全表扫描。
参数含义与代价模型
PostgreSQL的代价单位是抽象的，默认将顺序读取一个数据页的成本定义为1，即seq_page_cost = 1。随机读取一个数据页的成本定义为4，即random_page_cost = 4。此外还有CPU代价参数cpu_tuple_cost和cpu_index_tuple_cost等，但对于大表查询，I/O代价通常起决定性作用。
优化器在评估索引扫描时，会计算索引页的随机读取代价加上堆表的随机读取代价，再与全表顺序扫描的代价进行比较。全表扫描的代价约等于表的总页数乘以seq_page_cost，而索引扫描的代价则包含索引页随机读取和表页随机读取，很多时候还涉及回表操作。当random_page_cost远大于seq_page_cost时，优化器会认为随机读非常昂贵，从而倾向于选择顺序扫描。即使索引能过滤掉大量行，过高的随机代价估算也会让优化器放弃索引。
例如，一个包含100万行的表，数据页约10000页，索引高度为3。全表扫描代价约10000。索引扫描如果过滤后只需回表100行，实际随机读约100+3页，但如果random_page_cost为4，估算代价约412，已经低于全表扫描，通常还是会选索引。可当过滤条件选择性不好，比如需要回表50000行，随机读约50003页，估算代价高达200012，远超全表扫描，优化器就会选择全表扫描。在机械硬盘上这种选择合理，但在SSD上随机读延迟可能只有顺序读的1.5倍，真实代价远没有这么高。
如何发现参数设置不合理
最直观的判断方法是使用EXPLAIN (ANALYZE, BUFFERS)查看实际执行计划与代价估算。如果一个查询在分析阶段预估使用全表扫描，但实际执行时索引扫描更快，就说明random_page_cost可能被设置得过高。反过来，如果优化器频繁选择索引扫描，但实际执行时间比强制全表扫描更长，则可能random_page_cost设置过低。
可以通过对比强制计划来验证。例如对一个查询，先让优化器自由选择计划，然后用SET enable_seqscan = off强制使用索引扫描，分别执行并比较实际耗时。如果强制索引扫描明显更快，而优化器默认选择了全表扫描，就需要降低random_page_cost。这种做法能够排除数据缓存、统计信息不准等干扰因素，直接体现随机I/O代价估计的问题。
-- 查看默认计划 EXPLAIN (ANALYZE, BUFFERS, TIMING) SELECT * FROM orders WHERE customer_id = 12345; -- 强制禁用顺序扫描，再查看计划 SET enable_seqscan = off; EXPLAIN (ANALYZE, BUFFERS, TIMING) SELECT * FROM orders WHERE customer_id = 12345;
另一个重要信号是pg_stat_user_tables中顺序扫描次数异常高。如果业务中存在大量应该走索引的点查，但顺序扫描占比很高，同时表数据量较大且索引可用，往往说明代价模型需要调整。不过需要排除统计信息过期、索引失效或查询条件书写不当等因素。
存储介质的性能测试也能提供依据。使用PostgreSQL自带的pg_test_fsync或系统工具fio测量随机读与顺序读的实际延迟比值。例如在NVMe SSD上，随机读与顺序读的延迟差距通常只有1.2到1.8倍，此时将random_page_cost设置为1.5左右更符合实际。
调整策略与操作步骤
调整前应先在会话级别进行测试，使用SET random_page_cost = 1.5;观察执行计划变化和实际执行时间。不要直接在全局配置文件中修改，避免影响所有查询。建议挑选几个典型的慢查询，分别在默认参数和新参数下执行EXPLAIN ANALYZE，记录实际耗时、缓冲命中数以及计划选择。如果新参数下执行计划更合理且真实性能提升，再考虑全局应用。
-- 会话级调整示例 SET random_page_cost = 1.5; SET seq_page_cost = 1; -- 重新分析目标查询 EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM large_table WHERE indexed_column = 100; -- 查看当前参数值 SHOW random_page_cost; SHOW seq_page_cost;
对于不同表空间或不同存储介质的数据库，PostgreSQL允许在表空间级别单独设置这两个参数。通过ALTER TABLESPACE命令可以覆盖全局设置，例如将热数据表空间放在SSD上，设置较低的random_page_cost，而冷数据放在机械盘上保持较高值。这样优化器能够根据数据位置做出更精细的代价估算。
-- 为SSD表空间设置较低的随机读代价 ALTER TABLESPACE ssd_tablespace SET (random_page_cost = 1.2, seq_page_cost = 1); -- 为机械盘表空间保持默认或更高 ALTER TABLESPACE hdd_tablespace SET (random_page_cost = 4, seq_page_cost = 1);
调整幅度不宜过于激进。random_page_cost最低不应低于seq_page_cost，否则随机读会被认为比顺序读还便宜，这违背物理常识，可能导致优化器选择大量随机I/O的索引扫描，反而拖慢系统。一般建议从默认值4逐步下调，每次降低0.5或1，分别测试典型工作负载。对于纯SSD环境，1.5到2.0是常见合理区间；对于混合存储，需要根据数据实际分布分别设置。
调整后应持续监控数据库的整体性能指标，包括平均查询延迟、缓冲命中率、磁盘I/O等待时间等。可以使用pg_stat_statements扩展跟踪关键查询的执行次数和平均耗时，对比调整前后的变化。如果发现某些查询性能下降，应立即回滚参数。
实践案例与注意事项
某电商平台的订单表约5000万行，存储在全闪存阵列上。默认参数下，一个按客户ID查询最近订单的SQL被优化器规划为并行全表扫描，因为random_page_cost为4导致索引扫描代价估算极高。实际测试中，强制索引扫描仅需8毫秒，而全表扫描需要超过1秒。将全局random_page_cost调整为1.4后，优化器自动选择了索引扫描，该接口的P99延迟从900毫秒降至15毫秒。
需要注意的是，random_page_cost的调整并不是万能的。如果表很小，全部数据可以缓存到shared_buffers中，那么I/O代价本身就不重要，调整参数影响有限。如果统计信息严重失真，优化器无论使用什么代价参数都难以做出正确选择。因此调优前必须确保ANALYZE已经运行且统计信息足够准确。同时，对于带有LIMIT的查询，优化器还会考虑启动代价和总代价，random_page_cost只影响I/O部分，可能还需要结合其他参数如effective_cache_size一起调整。
另外一个常见的误区是只调整random_page_cost而忽略seq_page_cost。seq_page_cost是所有I/O代价的基准单位，虽然默认值为1通常不需要改变，但如果你的存储顺序读性能极差或极好，调整seq_page_cost会改变整个代价比例尺。一般不建议修改seq_page_cost，除非你对存储性能有精确的测量数据。
最后，每次调整参数都应当记录变更前后的执行计划和实际性能数据。PostgreSQL没有内建的参数变更审计，但可以在变更前用pg_stat_statements导出基准数据，变更后对比。这种方式能够量化调优效果，也便于在出现问题时快速定位原因。
PostgreSQLrandom_page_costseq_page_cost修改时间：2026-08-25 21:33:16