work_mem并非越大越好，过高会导致多操作并发内存超限、触发swap而拖慢查询；应结合EXPLAIN分析溢出情况，按场景分级设置，并监控blks_read、swap及响应时间验证效果。
work_mem 设置太高反而让查询更慢
PostgreSQL 的 work_mem 不是“越大越好”，它控制每个排序操作或哈希表能用的内存上限。设成 1GB 看似爽，但一个复杂查询里可能触发几十个并行排序（比如多层 JOIN + ORDER BY + DISTINCT），实际内存占用会是 work_mem × 并行操作数，瞬间吃光物理内存，触发 swap，查询从秒级变分钟级。
实操建议：
- 先查当前活跃查询的内存使用：
SELECT pid, query, work_mem FROM pg_stat_activity WHERE state = 'active'; - 用
EXPLAIN (ANALYZE, BUFFERS)看执行计划里有没有大量Sort Method: external merge Disk—— 这说明排序溢出了磁盘，work_mem确实不够；但如果看到Sort Method: quicksort却依然慢，大概率是设太高导致系统级抖动 - 推荐起始值：单机开发环境设
4MB～16MB，生产 OLTP 系统保守设8MB，OLAP 场景可按需局部提高（见下一条）
用 SET LOCAL 在单个查询里临时调高 work_mem
全局改 work_mem 风险大，真正需要加速的只是某几个报表类查询。PostgreSQL 支持会话级、事务级甚至语句级覆盖，SET LOCAL 是最安全的选择 —— 它只对当前事务生效，事务结束自动还原。
实操建议：
- 在应用代码里执行查询前加一句：
BEGIN; SET LOCAL work_mem = '256MB'; SELECT ... ; COMMIT; - 注意：不能在函数内部用
SET LOCAL影响调用者的事务（除非函数标记为VOLATILE且显式开启事务） - 如果用连接池（如 pgbouncer），确认它没把
SET语句过滤掉 —— 某些池子默认禁用运行时参数修改
work_mem 和 maintenance_work_mem、shared_buffers 的关系
这三个参数常被一起调，但作用域和触发时机完全不同：work_mem 管排序/哈希等“计算过程”，maintenance_work_mem 只影响 VACUUM、CREATE INDEX、ALTER TABLE 等维护操作，shared_buffers 是数据页缓存，和计算内存无关。混着调容易误判瓶颈。
实操建议：
- 查索引创建慢？先看
maintenance_work_mem，不是work_mem - 观察
shared_buffers命中率（用pg_stat_bgwriter或pg_buffercache扩展），命中率低于 95% 再考虑加大，否则纯属浪费 -
work_mem调整后，务必监控pg_stat_database.blks_read和blks_hit—— 如果磁盘读没降反升，说明内存分配策略已干扰到共享缓冲区的 LRU 管理
并发查询多时，work_mem 实际开销远超预期
很多人忽略一点：PostgreSQL 的 work_mem 是“每个操作节点”独立分配的。一个带 3 个 JOIN 和 1 个窗口函数的查询，执行计划里可能有 5 个以上需要内存的节点（Sort、Hash Join、Aggregate 等），每个都按 work_mem 上限申请 —— 不是总共用这么多，而是“最多可能用 5×”。
实操建议：
- 用
EXPLAIN (VERBOSE)看执行计划里的 Node Type，数清楚有多少个Sort、Hash、Materialize - 高峰期并发 50 个查询，每个平均 3 个内存节点，
work_mem = 64MB就意味着理论峰值内存需求：50 × 3 × 64MB ≈ 9.6GB —— 这还没算连接本身、shared_buffers、操作系统开销 - 真正稳的办法是：压测时用
top或ps aux --sort=-%mem直接看 postgres 进程 RSS，比算理论值靠谱得多
work_mem 的坑不在怎么设，而在怎么验证它没让系统更糟 —— 每次调整后盯住交换分区使用率和查询响应时间的双曲线变化，比任何文档都准。
