在 PostgreSQL 的性能调优领域，内存参数的配置往往是决定数据库响应速度的关键因素。shared_buffers与work_mem作为两个核心的内存管理参数，分别控制着数据缓存与查询操作的内存分配，它们之间存在着复杂的相互作用关系。理解这两个参数的工作机制，并针对不同的业务负载模式进行精细化配置，是实现数据库高性能运行的基础技能。本文将从内存架构入手，深入剖析这两个参数的调优策略，并提供可直接落地的量化配置方案。
PostgreSQL 内存架构解析
在深入探讨具体参数之前，有必要理解 PostgreSQL 的内存管理模型。PostgreSQL 的内存使用可以分为两个层次：共享内存与会话内存。共享内存由所有数据库连接共享，主要用于缓存数据页和存储全局元信息；会话内存则随着连接的建立而分配，随着连接的断开而释放，用于存储查询执行过程中的临时数据。这两层内存的管理策略直接影响着数据库的整体性能表现。
shared_buffers是共享内存的核心组成部分，它相当于数据库自己的「数据缓存层」。当 PostgreSQL 需要读取数据时，会优先检查shared_buffers中是否已经存在所需的数据页，如果命中则直接返回数据而无需进行磁盘 IO；如果未命中，则需要从磁盘读取数据并将其缓存到shared_buffers中以备后续使用。这种机制可以显著减少磁盘 IO 次数，从而提升查询响应速度。然而，shared_buffers并非越大越好，因为 PostgreSQL 与操作系统之间存在「双重缓存」的问题 —— 操作系统本身也有自己的页面缓存（Page Cache），当shared_buffers设置过大时，可能会导致数据同时存在于两个缓存中，造成内存浪费。
work_mem则属于会话内存的范畴，它定义了单个查询操作（如排序、哈希连接、哈希聚合等）在将数据写入临时磁盘文件之前可以使用的最大内存量。值得注意的是，work_mem是按操作（per-operation）分配的，而非按连接（per-connection）。这意味着一个复杂的查询可能会同时使用多个work_mem内存块，每个操作各自独立分配内存。因此，即使work_mem的设置看似不大，在高并发场景下也可能导致总体内存消耗超出预期。
shared_buffers 调优深度指南
对于专用数据库服务器，shared_buffers的推荐起始值为系统总内存的百分之二十五，但通常不应超过百分之四十。这一经验法则的出发点在于为操作系统保留足够的内存用于页面缓存和其他系统进程。以一台三十二 GB 内存的服务器为例，shared_buffers设置为八 GB 是一个合理的起点；而在六十四 GB 内存的服务器上，十六 GB 的配置通常能够满足大多数业务场景的需求。
评估shared_buffers配置效果的核心指标是缓冲区命中率（Buffer Cache Hit Ratio）。健康的数据库系统应该保持百分之九十九以上的缓冲区命中率，这意味着几乎所有的数据读取请求都能在内存中满足。如果命中率低于百分之九十五，则需要考虑增加shared_buffers的大小，或者对业务查询进行优化以提高数据局部性。可以通过以下 SQL 查询获取缓冲区命中率：
SELECT
ROUND(100.0 * SUM(blks_hit) / NULLIF(SUM(blks_hit) + SUM(blks_read), 0), 2) AS cache_hit_ratio
FROM pg_stat_database;
在监控工具方面，pg_buffercache 扩展是一个非常有用的辅助工具。通过安装该扩展，可以直观地查看当前shared_buffers缓存了哪些表的数据、各表占用的缓存比例以及缓存的分布情况。这对于识别热点表和优化数据布局具有重要参考价值。需要特别注意的是，修改shared_buffers参数后需要重启 PostgreSQL 服务才能生效，因此在生产环境中进行配置调整时需要规划好维护窗口期。
对于超大规模内存的服务器（超过一百二十八 GB），shared_buffers的设置存在明显的边际效益递减现象。当超过三十二 GB 之后，继续增加该参数的收益显著降低，此时更明智的做法是依赖操作系统的页面缓存来管理热数据。此外，对于需要处理超大表全表扫描的 OLAP 场景，可以适当降低shared_buffers的占比，因为顺序扫描场景下操作系统的页面缓存往往能够更高效地管理数据。
work_mem 调优策略与风险控制
与shared_buffers不同，work_mem的调优需要更加谨慎，因为它直接关系到系统的内存稳定性。计算work_mem潜在内存占用的公式为：潜在内存使用等于最大连接数乘以work_mem再乘以每个查询的操作数。以默认配置为例，假设max_connections为一百，work_mem为四 MB，而每个查询平均包含三次需要使用work_mem的操作，那么在最坏情况下，仅work_mem就可能消耗约一点二 GB 的内存。
这种内存分配机制带来的风险在于，高并发场景下如果work_mem设置过大，可能瞬间耗尽系统内存并触发 OOM（Out of Memory）杀手进程。因此，对于 OLTP 类型的业务系统，work_mem的配置通常需要采取保守策略。推荐的计算方法是：将系统可用内存的百分之二十五除以最大连接数，从而得到一个相对安全的初始值。例如，一台六十四 GB 内存、配置了两百个连接数的服务器，其work_mem可以设置为约八十 MB。
识别work_mem不足的典型特征是查询出现磁盘排序（External Sort）。当排序操作无法在work_mem分配的内存中完成时，PostgreSQL 会使用临时文件进行外排序，这会显著增加查询延迟。可以通过EXPLAIN ANALYZE命令来检查排序是否使用了磁盘：
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders ORDER BY created_at DESC LIMIT 1000;
在输出结果中，如果看到「Sort Method: external merge Disk」的提示，说明排序溢出了磁盘；如果显示「Sort Method: quicksort Memory」则表示排序完全在内存中完成。对于需要执行复杂分析查询的场景，可以在会话级别临时调整work_mem：
SET LOCAL work_mem = '512MB';
SELECT ... FROM complex_analytical_query;
这种按需调整的方式既能满足复杂查询的内存需求，又不会影响整体系统的内存稳定性。
OLTP 与 OLAP 场景的协同调优方案
OLTP 与 OLAP 是两种截然不同的业务负载模式，它们对内存参数的需求存在显著差异，因此需要采用差异化的调优策略。OLTP 业务的特点是并发请求数量多、每个请求处理的数据量小且事务较短。在这种场景下，shared_buffers的命中率至关重要，因为频繁的小数据读取需要依赖缓存来避免磁盘 IO 瓶颈；而work_mem则应保持相对保守，以防止高并发下的内存耗尽。
针对 OLTP 场景的推荐配置如下：shared_buffers设置为总内存的百分之二十五，以确保热点数据能够常驻缓存；对于十六 GB 内存的服务器，max_connections通常不超过两百，此时work_mem设置为十六至三十二 MB 即可满足大多数事务处理需求。effective_cache_size 参数应设置为总内存的百分之五十至七十五，这是查询规划器的参考信息，告诉它可以预期的缓存空间大小，从而做出更优的执行计划选择。
OLAP 场景则呈现出相反的特征：并发请求数量较少，但每个请求需要处理的数据量巨大，涉及复杂的连接、聚合和排序操作。在这种场景下，shared_buffers的作用相对降低，因为大规模顺序扫描更依赖于操作系统的页面缓存；而work_mem则需要配置得足够大，以便复杂查询能够在内存中完成关键操作，避免频繁的磁盘 IO。以数据仓库类应用为例，即使将work_mem设置为一至四 GB 也是合理的，因为同时运行的复杂查询数量通常有限。
对于混合负载场景，需要在两个极端之间寻找平衡点。一种可行的策略是在全局配置中采用较为保守的work_mem设置，而对于已知的复杂分析查询，通过会话级别或资源队列的方式临时提升其内存配额。另一种思路是使用 PostgreSQL 的资源组（Resource Groups）功能，为不同类型的工作负载分配不同的内存配额，从而实现精细化的资源管理。
监控体系与调优流程
建立完善的监控体系是实现内存参数持续优化的基础。日常监控应关注以下关键指标：缓冲区命中率应维持在百分之九十九以上；pg_stat_statements扩展记录的临时文件写入量（temp_blks_written）应尽可能为零或极低；系统内存使用率应保持稳定，避免频繁的内存交换（Swap）。通过定期收集和分析这些指标，可以及时发现潜在的内存瓶颈并采取预防措施。
调优流程应该遵循「监控 — 分析 — 调整 — 验证」的迭代循环。首先收集当前系统的性能基线数据，包括内存使用情况、缓冲区命中率、查询延迟分布等；然后根据分析结果确定调优方向，优先调整影响最大的参数；每次调整后进行充分的压力测试，验证配置变更的效果并观察是否存在负面影响。由于shared_buffers的修改需要重启数据库，建议在进行该参数的调整时做好充分的测试和回滚准备。
在追求性能优化的同时，必须始终将系统稳定性放在首位。过于激进的内存配置可能导致内存耗尽，进而引发服务中断；过于保守的配置则无法充分发挥硬件的性能潜力。找到这个平衡点需要对业务特性有深入的理解，并在实践中不断微调。对于关键业务系统，建议在非生产环境进行充分的配置验证后再应用于生产环境。
参考资料：PostgreSQL 官方文档（19.4 Resource Consumption）、OneUptime《How to Tune shared_buffers and work_mem in PostgreSQL》（2026 年 1 月）。