hash join内存按操作节点独享计算，每个hash join、sort等各自独立申请work_mem上限；整桶刷出机制导致内存不足时性能断崖下跌超10⁵倍，需结合explain与pg_stat_progress_hash精准诊断并用set local临时调优。

Hash Join内存消耗是按操作节点独享计算的

PostgreSQL 的 work_mem 不是给整个查询用的，而是每个哈希操作（比如一个 Hash Join、一个 Sort、一个 DISTINCT）各自独立申请的上限。一个查询里嵌套两个 Hash Join，就可能同时吃掉 2×work_mem；如果还开了并行（max_parallel_workers_per_gather = 4），单个 Hash Join 最多消耗 4×work_mem。

常见误判是：看到查询慢，查到有 Hash Join，就全局把 work_mem 设成 '128MB'，结果并发 50 个连接时，理论峰值内存占用达 6.4GB，直接触发 OOM 或 swap。

• 估算单个 Hash Join 内存需求：驱动表行数 × (Join 键长度 + 8 字节指针) × 1.5（1.5 是哈希填充因子预留）
• 中小负载建议从 '32MB' 起步；高分析负载可试 '64MB'；超过 '128MB' 必须评估并发压力
• 临时调优务必用 SET LOCAL work_mem = '64MB'，仅当前事务生效

Hash 表构建不是“渐进式缓存”，而是整桶刷出

当 work_mem 不足时，PostgreSQL 不会只把“一部分”哈希桶写磁盘，而是整批刷出——一旦某个桶序列填满内存上限，整个桶组（bucket group）就被落盘为临时文件。后续每次 probe 都要重新读磁盘，访问延迟从纳秒级指针跳转变成毫秒级随机寻道，性能放大超 10⁵ 倍。

临时文件默认放在 pg_temp_* 目录，不走 shared_buffers 缓存，OS page cache 也难命中（因访问模式高度随机）。

• 日志里出现 writing to disk due to insufficient memory 就是明确信号
• EXPLAIN (ANALYZE, BUFFERS) 中对应 Hash 节点的 Disk Usage 字段非零 → 确认已落盘
• pg_stat_progress_hash 视图中 hash_probe_total_buckets / hash_buckets_used 比值 > 3 → 桶严重稀疏，说明 work_mem 太小被迫建了大量空桶

类型不一致或数据倾斜会让内存白费

即使 work_mem 设得足够大，Hash Join 仍可能大量耗内存甚至落盘，问题常出在语义层而非数值层：

• JOIN 字段类型不一致，例如 CAST(u.id AS TEXT) = o.user_id → 强制转换导致索引失效、优化器误判驱动表大小，硬上 Hash Join
• 数据倾斜：执行 SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY 2 DESC LIMIT 5，若 TOP1 频次 > 平均值 × 10 → 加内存无效，该考虑预过滤或改用 Merge Join
• 统计信息过期：大表增删改超 20% 后未运行 ANALYZE table_name → 优化器低估 build table 大小，runtime 才发现放不下
• 隐式转换阻断分区剪枝 → 分区表 JOIN 时扫描全部子表，build 表体积远超预期

连接池和单位错误会导致 SET 失效

你写了 SET work_mem = '64MB'，但实际没生效，常见静默失败点：

• 写成 '64M'（缺 B）→ PostgreSQL 静默转为 64 字节，等于没设
• 使用 pgbouncer 等连接池，默认拦截 SET 命令 → 需确认其 ignore_startup_parameters 未屏蔽 work_mem
• 同一查询含多个内存敏感操作（Hash Join + Sort + GROUP BY）→ 总内存是叠加的，但你只调了单个额度
• shared_buffers 或 effective_cache_size 调再高也没用 —— 它们不参与哈希表构建

真正卡住的地方往往不在数值大小，而在“谁在用”和“怎么用”：一个查询里三个 Hash Join，哪怕每个只吃 32MB，也意味着至少 96MB 实时内存占用；而 pg_stat_progress_hash 只反映主进程状态，worker 落盘了你也看不到。