确认Hash Join是否真落盘需先查EXPLAIN(ANALYZE,BUFFERS)中Hash节点Disk Usage是否非零，再验pg_stat_progress_hash中hash_probe_total_buckets/hash_buckets_used比值是否超3，同时排除数据倾斜与类型不一致。
怎么确认Hash JOIN真在落盘
别一看到慢就调 work_mem，先看证据。执行 EXPLAIN (ANALYZE, BUFFERS)，重点找 Hash 节点下的 Disk Usage 字段：如果为 0，说明根本没写磁盘，调内存纯属白忙。再查 pg_stat_progress_hash（PostgreSQL 12+ 支持），算 hash_probe_total_buckets / hash_buckets_used 比值——超过 3 就是桶太稀疏，work_mem 确实小了；低于 2 则大概率是数据倾斜或类型不一致导致的假性溢出。
work_mem该设多大才起作用
work_mem 不是给整个查询用的，而是每个 Hash Join、Sort 或 DISTINCT 操作各自独享的上限。一个查询里有两个 Hash Join，就可能吃掉 2×work_mem；开了并行（max_parallel_workers_per_gather = 4），单个 Hash Join 最多消耗 4×work_mem。
- 估算下限：对驱动表 Join 键粗略计算 ——
(行数 × (键长度 + 8)) × 1.5（1.5 是哈希填充因子） - 中小负载建议从
'32MB'起步；高分析负载可试'64MB'；超过'128MB'必须评估并发压力 - 单位必须写全：
'64MB'有效，'64M'会被静默转成 64 字节，等于没设
为什么SET了还是落盘
常见静默失败点：
- 连接池如
pgbouncer拦截SET命令 → 检查其ignore_startup_parameters是否屏蔽了work_mem - 同一查询含多个 Hash/Sort/DISTINCT → 总内存是叠加的，但你只给了单个操作额度
- 用了
SET work_mem = '64MB'全局改 → 容易引发 OOM；应改用SET LOCAL work_mem = '64MB'，仅当前事务生效 -
shared_buffers或effective_cache_size再大也没用 —— 它们不参与哈希表构建
临时表或改 JOIN 策略有时更有效
如果调大 work_mem 仍无效，大概率是优化器误判或数据问题：
- JOIN 字段类型不一致（比如
CAST(u.id AS TEXT) = o.user_id）→ 强制转换导致索引失效，优化器硬上 Hash Join，调内存无解 - 统计信息过期 → 大表增删改超 20% 后未运行
ANALYZE table_name，优化器低估驱动表大小 - 数据倾斜严重（TOP1 频次 > 平均值 × 10）→ 加内存只是把桶建得更多，IO 更糟；此时该加预过滤或换
Merge Join - 小表驱动大表且右表有索引 →
SET enable_hashjoin = off强制走 Nested Loop，反而更快（仅用于诊断）
pg_stat_progress_hash 只反映主进程状态，worker 落盘了你也看不到。 
