在数据库性能调优的领域，内存配置是决定响应时间的关键因素。对于 PostgreSQL 而言，尽管其拥有优秀的查询优化器，但若底层的内存参数配置不当，再精巧的 SQL 语句也可能沦为磁盘 I/O 的奴隶。PostgreSQL 的内存架构主要分为两层：一层是所有连接共享的缓冲区 (shared_buffers)，另一层是每个操作独占的工作内存 (work_mem)。理解这两者的区别与联系，是避免 “高配机器跑不出高性能” 的第一步。
shared_buffers：不是越大越好
shared_buffers 是 PostgreSQL 用于缓存数据页的共享内存区域。在一个专用数据库服务器上，官方文档建议将其设置为系统总内存的 25% 左右。这个数值看起来很诱人 ——64GB 的机器配 16GB 缓存，听起来很充裕。然而，这里隐藏着一个常见的陷阱：PostgreSQL 并不是唯一一个需要内存的进程。现代操作系统的 Page Cache 同样在高效地缓存磁盘数据。
如果将 shared_buffers 设置得过高（例如超过 40%），会导致 “双重缓存” 问题：同一份数据既存在于 PostgreSQL 的共享缓冲区中，又存在于操作系统的 Page Cache 中。这不仅浪费了宝贵的内存，还可能导致内核态与用户态之间的数据拷贝开销增加，反而降低了性能。因此，在大内存机器上，适度 “让出” 部分内存给 OS，往往能获得更优的整体吞吐量。此外，shared_buffers 的调整需要重启数据库服务才能生效，这也意味着它不适合作为频繁变动的参数，而应在系统上线前进行基准测试后确定。
work_mem：高并发下的隐形炸弹
如果说 shared_buffers 是 “静态” 的池子，那么 work_mem 就是 “动态” 的利刃。它控制着排序（Sort）、哈希表（Hash Join）等操作在写入临时磁盘文件之前可以使用的内存量。增大 work_mem 可以显著减少磁盘排序带来的性能损耗，让复杂的 ORDER BY 或 JOIN 操作在内存中飞速完成。然而，在高并发场景下，work_mem 是一个极具风险的参数。
危险之处在于其分配机制。work_mem 不是按 “数据库连接” 分配的，而是按 “查询操作” 分配的。一个复杂的 SQL 查询可能包含多个并行的排序或哈希操作，每个操作都会尝试申请 work_mem 大小的内存。更糟糕的是，如果有 200 个并发连接同时执行这样的查询，总内存消耗量将是：200 (连接数) * work_mem * 操作数。如果你的 work_mem 设置为 64MB，即使只有 10 个并发操作，也可能瞬间吃掉 640MB 内存。一旦估算失误，数据库进程会因 Out of Memory (OOM) 被系统强制杀死。
实战配置与动态调整策略
因此，配置 work_mem 不能依靠简单的经验百分比，而需要结合业务负载进行精确计算。一个推荐的保守起始公式是：(系统总内存 * 0.25) / 最大连接数。以 64GB 内存、max_connections=200 的服务器为例，初始的 work_mem 约为 80MB。
除了全局配置，更推荐的做法是利用 PostgreSQL 的会话级设置。对于那些需要大量内存的特定分析查询（如报表类），可以在事务开始时使用 SET LOCAL work_mem = '1GB' 来临时扩容，这样既保证了单次查询的性能，又避免了在全局层面引发内存雪崩的风险。配套的参数 hash_mem_multiplier（默认 2.0）允许哈希操作使用比普通排序更多的内存，在内存压力可控的前提下，提升哈希关联的效率。
监控与迭代优化
调优不是一劳永逸的工作。我们需要建立监控机制来验证参数的有效性。首先，通过 pg_stat_statements 扩展，我们可以清晰地看到哪些查询正在 “spill to disk”（溢写到磁盘）。观察 temp_blks_written 字段，如果发现大量临时块被写出，说明当前的 work_mem 无法满足内存排序的需求，需要适度增加，或者检查查询逻辑是否可以通过添加索引来优化。
其次，pg_buffercache 扩展能帮助我们可视化 shared_buffers 的使用情况。监控 buffer cache hit ratio（缓存命中率），如果该比率低于 99%，可能意味着缓存容量不足，或者存在大量全表扫描的 “大查询” 正在污染缓冲区，此时需要考虑优化查询或者增加 shared_buffers。
最后，别忘了 maintenance_work_mem。它用于 VACUUM、CREATE INDEX 等维护操作。由于这些操作通常是串行运行的，将其设置得比 work_mem 大得多（例如 1GB-2GB）是安全的，能大幅缩短索引创建和垃圾回收的时间。
资料来源：
- PostgreSQL Documentation: 19.4. Resource Consumption (https://www.postgresql.org/docs/current/runtime-config-resource.html)
- OneUptime Blog: How to Tune shared_buffers and work_mem in PostgreSQL (https://oneuptime.com/blog/post/2026-01-25-postgresql-shared-buffers-work-mem-tuning/view)