PostgreSQL 教程: 优化 random_page_cost 设置

七月 10, 2026

摘要：在本教程中，您将学习如何在 PostgreSQL 中优化random_page_cost设置。

核心议题与背景

在 PostgreSQL（简称 PG）中，基于成本的查询优化器（Cost-based Optimizer）通过计算不同执行计划的资源消耗来选择最优路径。random_page_cost 是影响查询计划的最重要配置参数之一。

诞生背景：PG 的成本模型诞生于 2000 年左右（约 25 年前），当时的存储介质以机械硬盘（HDD）为主。

默认值：

核心疑问：当前硬件已被 SSD（固态硬盘）甚至 NVMe 主导，且操作系统缓存大幅优化，4.0 的默认值是否过时？业界普遍建议在 SSD 环境下将其调低，这真的正确吗？

采用早期的基准测试方法，通过对比“强制索引扫描（随机 I/O）”与“顺序扫描（顺序 I/O）”的实际耗时，会得出令人意外的结论：

机械硬盘（HDD）：真实的随机/顺序 I/O 成本比率高达 ~140。
现代固态硬盘（SSD）：真实的随机/顺序 I/O 成本比率约为 ~27 至 28。
关键结论：即使在 SSD 上，真实的随机 I/O 物理成本也远高于默认值 4.0。4.0 这个默认值从始至终就不仅仅是底层物理 I/O 成本的真实反映。

既然真实的物理 I/O 成本差距是 27 倍，如果把 random_page_cost 设置为 30 会怎样？

表象：可能会极大地优化某些在隔离环境下运行的单个查询。

后果：会严重拖累整个数据库系统的全局性能。

根本原因（成本模型的局限性）：

1. 未考虑缓存效应（Caching Effects）：PG 的成本模型非常简化，它不知道当前“活跃数据集”（如最近一周的热点订单）有哪些正好在操作系统的页面缓存（Page Cache）中，也没有将内存计入成本消耗。

2. 忽略了并发影响：查询规划器在计算成本时，假设该查询是数据库中唯一正在运行的任务。

3. 内存淘汰的隐性成本（重点对比）：

顺序扫描（Sequential Scan）：为了获取 1GB 的目标数据，可能会直接将整张 100GB 的表读入缓存。这种操作会产生极高的隐性破坏，把缓存中其他查询真正需要的数据全部“挤出（Eviction）”。
随机扫描 / 索引扫描（Index Scan）：虽然单次随机读取的物理代价更大，但它具有高度的数据局部性。它只精准读取需要的 1GB 数据，从而保护了宝贵的系统缓存。

在 SSD 上是否应该调低？ 应该。 因为相比于以前的机械硬盘，SSD 处理随机 I/O 的能力确实有了质的飞跃。如果 4.0 对于机械硬盘是合理的（历史证明其运转良好），那么对于 SSD 来说，将其适度调低（例如调整为 2.0）是合理的选择。
避免过度依赖自动化跑分工具 切勿仅凭一个简单的基准测试脚本或命令行工具算出的“真实 IO 比率”来直接设置该参数，因为这类工具无法模拟复杂的缓存状态。
系统级监控优先 性能调优是“提升单次查询性能”与“维护全局系统健康”之间的权衡。任何参数的调整必须由整体系统监控驱动。调整后，不仅要观察目标查询是否变快，更要监控其他并发查询是否受到负面影响，并进行小步迭代式优化。