确认Hash Join写磁盘是否真因work_mem不足：先查EXPLAIN (ANALYZE, BUFFERS)中Hash节点Disk Usage是否非零；若为0则未落盘，无需调work_mem；再看pg_stat_progress_hash中hash_probe_total_buckets/hash_buckets_used比值是否远大于3；同时排查数据倾斜（TOP1频次＞平均值×10）和统计信息过期。
Hash Join报“writing to disk due to insufficient memory”怎么确认真是work_mem问题？
不是所有Hash Join慢都该调work_mem——先得排除数据倾斜和统计信息过期这两个更隐蔽的根因。
用EXPLAIN (ANALYZE, BUFFERS)跑一遍慢查询，重点看Hash节点的Disk Usage是否非零；如果为0，那根本没落盘，别碰work_mem。
再查pg_stat_progress_hash（PostgreSQL 12+）：hash_probe_total_buckets / hash_buckets_used比值若远大于3，说明哈希桶严重稀疏，大概率是work_mem太小被迫建了过多桶，内存被浪费而非不够用。
快速验数据倾斜：SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY 2 DESC LIMIT 5。如果TOP1频次 > 平均值×10，加work_mem基本白费——此时该考虑分区裁剪、预过滤或改用Merge Join。
work_mem该设多少？别按“总内存÷连接数”硬算
work_mem是每个哈希操作（比如一个Hash Join、一个Sort）能独占的上限，不是整个查询或整个会话的总和。一个查询里嵌套两个Hash Join，就可能吃掉2×work_mem；开了并行（max_parallel_workers_per_gather = 4），最多消耗4×work_mem。
- 估算下限：对驱动表Join键做粗略内存预估——
(行数 × (键长度 + 8)) × 1.5（1.5是哈希填充因子） - 推荐起点：从
'4MB'开始，逐步试到'64MB'，每次只改当前会话：SET LOCAL work_mem = '16MB' - 别全局设高：
max_connections = 200时，work_mem = '64MB'理论峰值内存占用达12.8GB，极易触发OOM或swap
为什么调了work_mem还是写磁盘？这些细节常被忽略
即使数值看起来够，Hash Join仍可能落盘，问题往往出在并发、并行或操作叠加上：
- 同一查询含
Hash Join + Sort + DISTINCT，三者各自申请work_mem，总开销是三倍 - 用了
parallel query，每个worker进程都独立申请work_mem，但pg_stat_progress_hash只反映主进程状态，容易误判 -
work_mem单位是字节，但配置里写'64MB'才生效；写成67108864也行，但错写成'64M'（少个B）会被静默转成64字节，直接崩 - 别指望
shared_buffers或effective_cache_size能“帮忙”——它们不参与哈希表构建，调了也没用
临时表+索引有时比死磕work_mem更有效
当JOIN前有强过滤条件（如WHERE status = 'paid' AND created_at > '2024-01-01'），先物化中间结果，比硬扛全量Hash更稳。
建临时表：CREATE TEMP TABLE tmp_orders AS SELECT * FROM orders WHERE ...，它走temp_buffers内存池（默认8MB），不挤占work_mem；还能立刻加索引：CREATE INDEX ON tmp_orders(user_id)，后续JOIN就可能转成Nested Loop或Merge Join，彻底绕开哈希内存瓶颈。
但注意：只有中间结果行数比原表少**一个数量级以上**（比如100万→5万），才值得建临时表；否则纯内存计算反而更快。
真正卡住的地方，往往不是work_mem设多大，而是没意识到一个查询里可能同时跑着好几个哈希操作，还都按上限拿内存。
