hash join慢八成因work_mem不足致哈希表溢出磁盘，确认方法是执行explain(analyze,buffers)查temp read/write量、io时间占比超70%、shared hit下降而local hit暴增；work_mem需按“每操作节点独享”计算，建议中小负载设32mb、高分析负载64mb，临时调优用set local；若调大仍无效，需检查join字段类型一致、统计信息是否更新、优化器是否误选hash join。
Hash Join慢，八成是 work_mem 不够用，导致哈希表溢出到磁盘——这不是“有点慢”，而是IO爆炸、查询卡死的前兆。
怎么确认是 work_mem 不足引发的 Hash Join 性能问题
别猜，直接看执行计划里的真实 IO 行为：
- 运行
EXPLAIN (ANALYZE, BUFFERS)，重点看输出里有没有大量Temp Read或Temp Write块（比如几百 MB 甚至 GB 级别的临时读写） - 观察
Execution Time中 IO 时间占比：若超过 70%，基本可锁定为磁盘哈希导致 - 检查
Shared Hit/Read比例是否异常下降，同时Local Hit/Read暴增——说明哈希过程在本地内存不足，被迫用临时文件缓存 - 用
SHOW work_mem;查当前值，若仍是默认4MB或1MB，大概率就是它
work_mem 设多大才合适：不是越大越好，而是要算清楚
这个参数是“每个操作节点”独享的，不是整个查询或整个会话的总和。一个含 3 个 JOIN、2 个 ORDER BY 的查询，可能同时触发 5 个独立的哈希/排序操作，每项都最多吃掉你设的 work_mem。
- 公式参考：单连接可用上限 ≈ 总物理内存 × 0.25 ÷ 并发连接数 ÷ 3（留余量）。例如 64GB 内存、100 并发 → 单连接建议 ≤ 53MB，取整设
64MB更稳妥 - 生产环境常见安全值：中小负载设
32MB，高分析负载设64MB；超过128MB需严格评估并发压力，否则易触发 OOM - 临时调优别改全局：用
SET LOCAL work_mem = '64MB';在事务内生效，不影响其他查询 - 连接池（如 pgbouncer）可能拦截
SET命令，确认其配置允许运行时参数修改，否则该语句会被静默丢弃
为什么调了 work_mem 还没改善？这些坑最常被忽略
内存给了，但优化器没按预期走 Hash Join，或者走了却依然慢——问题往往不在内存本身：
- JOIN 条件字段类型不一致，比如
CAST(u.id AS TEXT) = o.user_id：索引失效，优化器被迫选 Hash，且无法缩小驱动表规模 - 统计信息过期：大表增删改超 20% 后未运行
ANALYZE table_name，优化器误估驱动表大小，以为能全放内存，结果 runtime 才发现溢出 - 本该用 Nested Loop 的场景硬塞 Hash：例如左表仅 100 行、右表有索引且
user_id高选择性，此时SET enable_hashjoin = off反而更快（仅用于诊断，勿上线） - 临时表滥用：不是所有中间结果都值得物化。只有“先过滤再 JOIN”类逻辑（如
WHERE status = 'active'后再连 5 张表）才适合建TEMP TABLE控制数据量
真正卡住 Hash Join 的，往往不是内存数字本身，而是驱动表到底有多大、优化器对它的估算准不准、以及 JOIN 条件能不能被索引真正利用——work_mem 只是最后一道闸门，前面任何一环松动，这道门开再大也挡不住磁盘 IO 洪水。
