注: 本文为安丫科技刘峰的原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。
PostgreSQL默认配置是为了“开箱即用”，而不是追求极致性能。
在企业级高性能服务器上，如果不进行系统性调优，海量硬件资源可能闲置，业务系统性能远未释放。
本文为DBA与系统工程师提供一套科学、规范的PostgreSQL初次参数优化指南，帮助你的数据库真正发挥大内存、多核心、高速存储的潜力。
01
基准环境设定
为确保参数建议的针对性与可量化性，本文基于以下硬件与业务负载模型展开：
服务器硬件配置
1）处理器 (CPU)
32 逻辑核心
2）内存 (RAM)
128 GB
3）存储系统
高性能NVMe固态硬盘（SSD）阵
业务负载模型
1）混合型工作负载 (Mixed OLTP/OLAP)
以高并发的在线事务处理（OLTP）为主，同时包含一定频率的中等复杂度分析与报表查询（OLAP）。
02
核心优化领域与参数深度解析
我们将围绕连接管理、内存、I/O子系统、并行处理及查询规划五个核心领域，进行系统性分析与配置。
连接与内存管理
1）max_connections
定义
设定数据库服务器允许的最大并发连接数。
推荐配置与理由 (400)
在PostgreSQL中，每个连接都是一个独立的操作系统进程，会消耗显著的内存资源。
因此，直接将此值设为数千以应对高并发是极其危险且不专业的做法。
400是一个为中大型应用预留的、合理的直接连接上限。
对于需要更高并发的场景，架构上的最佳实践是引入连接池中间件（如PgBouncer），它能以极小的开销复用少量（如50-100个）数据库连接，服务成千上万的应用请求。
2）shared_buffers
定义
设置数据库服务器将用于共享内存缓冲区的大小，这是PostgreSQL最核心的缓存区域。
推荐配置与理由 (64GB)
遵循业界公认的系统总内存25%的基准法则，对于256GB内存的服务器，64GB是理想的起点。
这为数据库核心缓存提供了海量的空间，能将绝大部分热数据（频繁访问的数据和索引）保留在内存中，从而最大程度地减少昂贵的磁盘I/O，同时为操作系统自身的文件系统缓存留有充足的余地。
3）effective_cache_size
定义
设置查询优化器对于可用磁盘缓存总量的估算值，此值包括shared_buffers和操作系统的文件系统缓存。
推荐配置与理由 (192GB)
此参数并不分配内存，而是"告知"优化器系统的真实缓存能力。
设定为系统总内存的75%，即192GB，能让优化器在评估查询计划时，充分信赖操作系统缓存的能力，从而更积极地选择依赖于缓存的高效执行路径（如索引扫描），而不是保守地选择可能导致大量磁盘读的全表扫描。
4）work_mem
定义
指定在写入临时磁盘文件之前，内部排序操作和哈希表可以使用的内存量。
推荐配置与理由 (64MB)
在高并发OLTP为主的混合负载下，work_mem的配置必须在加速OLAP查询和控制OLTP内存风险之间取得精妙平衡。
64MB是一个比默认值慷慨得多，但比纯OLAP场景更为保守的专业选择。
它能有效处理大部分中等复杂度的排序和哈希操作，避免其溢出到磁盘，同时将高并发下的内存溢出风险（并发操作数 * 64MB）控制在较低水平。
对于极少数超大型报表，应在会话级别通过SET work_mem动态提升。
5）maintenance_work_mem
定义
指定在维护性操作（如VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY）中可以使用的最大内存量。
推荐配置与理由 (4GB)
对于拥有256GB内存、可能管理着TB级数据的服务器，将维护工作内存提升至4GB，能够极大地加速大型表的索引重建、垃圾回收等操作。
这不仅缩短了维护窗口，更重要的是减少了维护操作对线上业务性能的干扰。
6）huge_pages
定义
控制服务器是否使用大内存页（Huge Pages）。
推荐配置与理由 (on)
强烈建议在操作系统层面配置足够的巨页，并在此处设置为on。
巨页可以显著减少CPU在内存地址翻译上的开销（降低TLB缓存未命中率），并能防止PostgreSQL的共享内存被操作系统错误地交换到磁盘，从而在大内存环境下获得更稳定、更优异的性能。
若操作系统配置有困难，可退回至try作为安全选项。
I/O子系统与持久化
1）min_wal_size & max_wal_size
定义
min_wal_size设置了只要WAL磁盘使用量保持在此设置之下，旧的WAL文件就会被回收再利用而不是被删除。
max_wal_size则定义了在自动检查点期间允许WAL增长到的最大尺寸。
推荐配置与理由 (4GB & 16GB)
对于写入密集型的高性能系统，大幅增加WAL日志文件的容量是减少检查点（Checkpoint）频率、平滑I/O峰值的核心手段。
4GB到16GB的范围为系统提供了巨大的缓冲，确保即使在写入高峰期，检查点也不会过于频繁地触发I/O风暴，从而避免周期性的性能抖动。
2）checkpoint_completion_target
定义
指定检查点完成的目标，作为检查点之间总时间的一部分。
推荐配置与理由(0.9)
这是现代PostgreSQL调优的最佳实践。
它将检查点的I/O负载尽可能均匀地分散在两个检查点间隔期90%的时间内完成，将集中的I/O"洪峰"削平成平稳的"溪流"，对保障低延迟响应至关重要。
3）wal_buffers
定义
设置用于在写入磁盘之前临时存储WAL数据的共享内存量。
推荐配置与理由 (16MB)
默认值较小。
将其增加到-1（自动设置为shared_buffers的1/32，在此例中约为2GB）在现代版本中是一个不错的选择，但16MB是一个经过长期验证的、能覆盖绝大多数高写入负载场景的、既安全又高效的经典值。
它能将多次小的I/O合并为一次大的I/O，显著提升事务吞吐量。
4）random_page_cost
定义
设置查询优化器对于一次非顺序（随机）磁盘页面读取的成本估算。
推荐配置与理由 (1.1)
这是针对NVMe SSD的"必调"参数。其默认值4.0是基于传统机械硬盘（HDD）随机读写性能远低于顺序读写的假设。将此值设置为接近顺序页面成本（seq_page_cost，默认为1.0），是向查询优化器传递的最强信号：随机I/O不再是性能瓶颈。这将根本性地改变查询计划的选择，使其更符合现代存储硬件的特性。
5）effective_io_concurrency
定义
设置可由单个PostgreSQL进程并发执行的同时进行的磁盘I/O操作的数量。
推荐配置与理由 (250)
对于由多个NVMe SSD组成的高性能RAID阵列，其并发I/O处理能力非常强。
250是一个合理的估算值，有助于优化器在执行位图堆扫描（Bitmap Heap Scans）等操作时，生成更高效的并行I/O计划。
CPU并行处理与查询规划
1) default_statistics_target
定义
为后续的ANALYZE操作设置默认的统计信息目标（样本量）。 推荐配置与理由 (550)
对于数据模型复杂、数据分布不均的企业级应用，默认的100个统计样本往往不足以让优化器做出最精确的判断。 将此值提升至500，可以为优化器提供更丰富的数据分布信息，从而生成更优的查询计划，尤其对包含复杂JOIN和WHERE条件的查询效果显著。
2) max_worker_processes&
max_parallel_workers
定义
max_worker_processes设置系统可以支持的最大后台进程数。max_parallel_workers设置系统可以支持的用于并行查询的最大工作进程数。 推荐配置与理由
(64 & 64) 将系统可用的后台工作进程总数及可用于并行查询的进程数，设置为与CPU逻辑核心数相等的64，是最大化硬件利用率的直接体现，为所有并行任务提供了充足的资源池。
3）max_parallel_workers_per_gather
定义
设置单个Gather或Gather Merge节点可以启动的最大工作进程数。
推
荐配置与理由 (8) 在64核的系统上，为单个查询节点分配8个并行工作进程，是一个在加速OLAP查询和保障OLTP并发之间取得的专业平衡。 它能让中等复杂度的分析查询获得显著的性能提升（理论上可达数倍），同时避免单个重度查询独占过多CPU资源，从而保护了核心交易业务的响应能力 。
4）max_parallel_maintenance_workers
定义
设置CREATE INDEX等维护命令可以启动的最大并行工作进程数。 推荐配置与理由 (8)
允许维护操作利用最多8个并行工作进程，与max_parallel_workers_per_gather保持一致。 在多核心服务器上，这能将大型表的索引创建时间缩短数倍，极大提升运维效率。
03
大家可以参照https://pgtune.leopard.in.ua/，生成属于自己的制定化参数。
基于以上分析，针对所述基准环境的postgresql.conf核心参数配置汇总如下：
# WARNING
# this tool not being optimal
# for very high memory systems
# DB Version: 17
# OS Type: linux
# DB Type: web
# Total Memory (RAM): 128 GB
# CPUs num: 64
# Connections num: 100
# Data Storage: ssd
max_connections = 100
shared_buffers = 32GB
effective_cache_size = 96GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 204600kB
huge_pages = try
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 64
max_parallel_workers_per_gather = 4
max_parallel_workers = 64
max_parallel_maintenance_workers = 4
04
任何一套静态参数配置都只是一个经过专业计算的“最佳起点”。
真正的卓越性能源于一个动态的、数据驱动的持续优化过程。在应用此配置后，后续的关键步骤包括：
1）启用并周期性分析pg_stat_statements扩展，以识别并优化高成本SQL。
2）建立全面的监控体系，持续追踪缓存命中率、检查点活动、索引效率及慢查询日志。
3）在预生产环境中进行负载测试，验证配置在模拟真实业务压力下的表现，并进行必要的微调。
通过这种“基准配置 + 持续监控 + 精细微调”的闭环方法，方能确保PostgreSQL在高性能硬件平台上，发挥出其全部潜能，为企业核心业务提供稳定、高效、可靠的数据支撑。
写在最后
任何参数配置都只是起点，持续监控与精细微调才是性能提升的关键。
通过分析高成本SQL、跟踪缓存命中率与慢查询，并在预生产环境中验证配置，你的PostgreSQL将在企业核心业务中发挥极致性能，为业务系统提供稳定、高效、可靠的数据支撑。
作者介绍
大家好，我是刘峰，安丫科技创始人 & 数据库技术高级讲师，专注于 PostgreSQL、国产数据库运维与迁移、数据库性能优化 等方向。
作为 PG中国分会官方授权讲师、PostgreSQL ACE 讲师认证专家，我长期活跃在一线项目实战中，拥有 10年以上大型数据库管理与优化经验，曾深度参与电信、金融、政务等多个行业的数据库性能调优与迁移项目。
欢迎关注我，一起深入探索数据库的无限可能，技术交流不设限！
📌 觉得有收获的话，记得点赞、收藏、转发支持一下哦，别忘了关注我获取更多数据库干货~
安呀智数据坊｜我们能做什么
无论你是业务系统的技术负责人，还是数据部门的第一响应人，我们都能为你提供可靠的支持：
数据库类型支持
Oracle MySQL PostgreSQL PG / SQL Server 等主流数据库
核心服务内容
性能优化 / 故障处理 / 数据迁移 / 备份恢复 / 版本升级 / 补丁管理
系统性支持
深度巡检 / 高可用架构设计 / 应用层兼容评估 / 运维工具集成
专项能力补充
定制课程培训 / 甲方团队辅导 / 复杂问题协作排查 / 紧急救援支持
📮 如果你有一张删不掉的表、一个跑不动的查询，或者一场说不清的升级风险，欢迎来找我们聊聊。
关键词回复(可见相应文章):
oracle、mysql、pg、postgresql、sql、性能优化、故障处理、数据迁移、备份恢复、版本升级、补丁管理、深度巡检、解决方案、架构设计......
有任何问题或疑问，欢迎加V进群探讨哦～
\ | /
★
动动你的手指
给【安呀智数据坊】加个星标吧~
这样你就不会丢下我啦~
记得加星标呀！
