Hash Join溢出磁盘是因为work_mem不足导致哈希表整桶刷盘，性能断崖式下降；需通过EXPLAIN(ANALYZE,BUFFERS)确认Disk Usage非零、排除数据倾斜与类型不一致后，按操作节点独享原则设32MB～64MB并用SET LOCAL临时调整。
为什么Hash Join会溢出到磁盘？
PostgreSQL 的 Hash Join 在构建哈希表时，会把内表（inner relation）全部加载进内存。如果内表太大，超出了 work_mem 限制，PostgreSQL 就会把部分哈希桶写入临时文件——这就是“溢出到磁盘”。一旦发生溢出，性能通常会断崖式下降，因为涉及大量随机 I/O 和多次磁盘扫描。
关键判断依据是执行计划中出现 Hash Cond 后紧跟 Buckets: N on disk: M 或 disk: XkB 字样，例如：
Hash Join (cost=100.00..2000.00 rows=5000 width=64)
Hash Cond: (t1.id = t2.t1_id)
-> Seq Scan on t1 (cost=0.00..1000.00 rows=10000 width=32)
-> Hash (cost=50.00..50.00 rows=2000 width=32)
Buckets: 2048 Batches: 2 Memory Usage: 128kB
-> Seq Scan on t2 (cost=0.00..50.00 rows=2000 width=32)
注意这里的 Batches: 2：表示已启用多批次（multi-batch），即发生了溢出；Memory Usage 接近或等于 work_mem 也是强信号。
如何确认并调整 work_mem 有效值？
work_mem 是单个查询操作（如排序、哈希）可使用的最大内存量，不是全局总内存。设得太高会导致并发查询争抢内存，甚至触发 OOM Killer；设得太低则频繁溢出。不能只看单条慢 SQL 的执行计划就盲目调大。
- 先查当前会话/全局值：
SHOW work_mem;（单位是 kB，比如4096表示 4MB） - 对特定查询临时调高（推荐）：
SET LOCAL work_mem = '64MB';（仅对当前事务生效） - 避免在
postgresql.conf中全局设为256MB这类大值——若并发 20 个查询，可能吃掉 5GB 内存 - 更稳妥的做法是按查询特征分级设置：在应用层或连接池（如 pgbouncer）中，对已知大数据量 join 的会话，用
SET SESSION work_mem = '32MB';
哪些替代方案比硬调 work_mem 更可靠？
单纯堆内存不是万能解。当内表真实大小远超可用内存（比如几十 GB），或并发压力大时，应优先考虑逻辑优化。
- 加过滤条件缩小内表：确保
WHERE子句尽可能早地作用于内表，例如把JOIN t2 ON ... WHERE t2.status = 'active'改为JOIN (SELECT * FROM t2 WHERE status = 'active') t2 ON ...，让子查询先裁剪数据 - 换用
Merge Join：如果两表在 join 列上都有索引且数据有序，强制使用SET enable_hashjoin = off;可能更稳定（但需验证排序成本） - 分区裁剪：若内表按时间/地区分区，确保
WHERE条件能命中具体分区，避免扫描全表 - 物化中间结果：对反复使用的内表子集，建
MATERIALIZED VIEW并定期刷新，再 join 它
监控和定位溢出的真实代价
光看执行计划里的 Batches 不够，要确认是否真的拖慢了查询。PostgreSQL 提供了细粒度统计：
- 开启
track_io_timing = on和log_min_duration_statement = 1000，在日志里搜IO timing，对比read/write时间占比 - 用
EXPLAIN (ANALYZE, BUFFERS)查看Shared Read Blocks和Temp Read Blocks：后者显著高于前者，说明磁盘读开销大 - 检查系统级指标：
iostat -x 1观察%util和await，若await持续 > 10ms，说明 I/O 已成瓶颈
真正棘手的是“伪溢出”：work_mem 足够，但哈希键分布极度倾斜（比如 90% 的行 key = 1），导致单个 bucket 超限而被迫落盘。这种情况调内存没用，必须从数据分布或业务逻辑上解决。
