Hash_Join慢且日志报“writing to disk due to insufficient memory”是因work_mem不足导致哈希表落盘，需先确认是否内存不足而非数据倾斜或统计信息过期，再合理调优work_mem并配合索引、分区等根治措施。
Hash_Join慢且日志报“writing to disk due to insufficient memory”
PostgreSQL在执行Hash_Join时，如果work_mem不足，会把哈希表写到磁盘临时文件，性能骤降——这不是算法问题，而是内存配置没跟上数据规模。典型症状是执行计划里出现Hash节点带disk字样，或日志中反复出现writing to disk due to insufficient memory。
关键判断：先确认是否真因work_mem过小导致溢出，而不是数据倾斜或统计信息过期。
- 用
EXPLAIN (ANALYZE, BUFFERS)看实际Hash节点的Memory Usage和Disk Usage字段 - 检查
pg_stat_progress_hash视图（v12+），观察hash_probe_total_buckets与hash_buckets_used比值是否远大于1（说明哈希桶严重浪费，可能因work_mem太小被迫建更多桶） - 排除数据倾斜：对Join键运行
SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY 2 DESC LIMIT 5，若最大频次超过平均值10倍以上，调work_mem效果有限
work_mem设多大才够用？不是越大越好
work_mem是每个操作（如一个Hash_Join、一个Sort）能独占的内存上限，不是整个查询或整个会话的总和。设太高会导致并发查询争抢内存，触发OOM或大量swap；设太低则频繁落盘。
- 估算下限：对小表（驱动表）做
Hash，至少需要容纳其全部Join键+关联行指针。粗略按(行数 × (键长度 + 8字节)) × 1.5算（1.5是哈希表填充因子预留） - 推荐起点：从
4MB开始测，逐步加到64MB，每次用相同SQL跑EXPLAIN (ANALYZE)对比Execution Time和Disk Usage - 注意作用域：全局设
work_mem = '64MB'影响所有连接；更安全的是在会话级改：SET LOCAL work_mem = '64MB'，仅对当前事务生效 - 别碰
shared_buffers或effective_cache_size来“间接”救Hash_Join——它们不参与哈希构建
为什么调了work_mem还是落盘？常见陷阱
即使work_mem数值看起来足够，Hash_Join仍可能写磁盘，原因往往藏在细节里：
- PostgreSQL按“每个哈希操作”单独分配
work_mem，但一个查询里可能有多个Hash_Join或嵌套Hash+Sort，总内存消耗是叠加的，而你只给了单个操作的额度 - 使用
parallel query时，每个worker进程都独立申请work_mem，比如max_parallel_workers_per_gather = 4，实际最多消耗4 × work_mem -
work_mem单位是字节，但配置里写'64MB'会被正确解析；写成64000000容易少零，写成64M（缺B）会静默失败回退到默认值 - Linux内核的
vm.overcommit_memory设为2时，可能因vm.overcommit_ratio限制，导致PostgreSQL申请不到足额内存，哪怕work_mem设得再高
真正有效的优化不止work_mem
单靠调work_mem是止痛片，不是根治方案。当表很大、Join键分布不均或查询并发高时，必须配合其他手段：
- 确保Join键上有索引：即使走
Hash_Join，索引也能加速小表扫描和过滤，减少参与哈希的行数 - 定期运行
VACUUM ANALYZE table_name，让优化器准确估算驱动表大小——若它误判小表为大表，会主动避开Hash_Join或选错构建顺序 - 考虑
SET enable_hashjoin = off强制改用Nested Loop（仅当驱动表极小且被索引精准定位时），或enable_mergejoin = on配合已排序字段 - 最硬核但有效：拆分超大事实表，按时间/租户分区，让每次
Hash_Join只面对百万级而非亿级数据
哈希溢出本质是内存与数据规模的匹配问题，而work_mem只是那个可调的旋钮。真正难的是判断该旋多大、旋几次，以及什么时候该换台机器、换种建模方式。
