Hash Join性能断崖源于work_mem不足导致整桶刷盘引发IO爆炸；需先用EXPLAIN(ANALYZE,BUFFERS)确认Disk Usage非零、排除数据倾斜与统计过期，再按节点独享原则设32MB～64MB并SET LOCAL临时调整。
HASH JOIN 本身不“消耗临时内存”，它消耗的是工作内存（work_mem / hash memory），而一旦不够，才被迫把哈希桶整批刷到临时存储（tempdb / pg_temp_*）——这才是你看到的“大量临时内存占用”的真实来源。
Hash Join 的内存分配机制是“独占式预分配”
PostgreSQL 和 SQL Server 都不会为 Hash Join 动态伸缩内存。它们按优化器估算的驱动表行数 × 键长度 × 填充因子（约1.5）一次性预留 work_mem 或等效内存空间。这个值不是上限，而是“最低保障”：如果实际数据超了，就立刻落盘；如果远小于，也照吃不误——比如估算 100 万行、键长 8 字节，work_mem 就被占掉约 12MB，哪怕实际只来 1 万行。
- SQL Server 中，
Hash Match算子会尝试将整个构建表（右表）载入内存建哈希表，内存不足时直接溢出到tempdb，触发ERROR 701或Could not allocate space for object 'dbo.#hash_table' - PostgreSQL 中，
work_mem是每个哈希操作（一个HASH JOIN、一个SORT、一个GROUP BY）各自独享的额度，不是整个查询共用——一条含 2 个 JOIN + 1 个 ORDER BY 的语句，可能同时吃掉 3 ×work_mem - Oracle 的
hash_area_size同理，且并行执行时每个 worker 进程都独立申请一份
为什么“估算偏差”比“数据量大”更容易导致溢出
真正卡死生产库的，往往不是千万级大表本身，而是优化器严重低估了参与哈希的数据规模：
- 统计信息过期：大表增删改超 20% 后未运行
ANALYZE，优化器以为驱动表只有 1 万行，结果 runtime 加载了 300 万行 - JOIN 字段类型不一致：比如
CAST(u.id AS TEXT) = o.user_id，索引失效 + 类型强制转换，优化器无法下推过滤，只能硬上全量哈希 - WHERE 条件写在 JOIN 外层：例如
FROM orders o JOIN users u ON o.user_id = u.id WHERE o.status = 'shipped'，数据库先做全量 JOIN，再过滤——驱动表本可缩到 5 万行，却用了 800 万行建哈希表 - 视图或 CTE 隐藏基数：查询里嵌套
SELECT * FROM (SELECT ... FROM a JOIN b) t，优化器常物化中间结果，体积反而比原表更大
怎么确认是不是 work_mem / hash 内存真不够
别靠猜，用真实指标验证：
- PostgreSQL：跑
EXPLAIN (ANALYZE, BUFFERS)，看 Hash 节点的Disk Usage是否非零；再查pg_stat_progress_hash，若hash_probe_total_buckets / hash_buckets_used > 3，说明桶太稀疏，work_mem设小了 - SQL Server：SSMS 图形执行计划里找
Hash Match属性中的SpillLevel > 0，或运行时查sys.dm_db_session_space_usage中internal_objects_alloc_page_count是否飙升 - Oracle：查
v$sql_workarea中policy是否为AUTO且actual_mem_used接近max_mem_used，同时number_passes > 1表示多轮磁盘读写
临时内存“占着不放”是设计使然，不是 bug
PostgreSQL 的 work_mem 内存由 backend 自己管理，不归还 OS；SQL Server 的 tempdb 溢出页在查询结束前一直被持有；Oracle 的 pga_aggregate_target 也是进程级生命周期。这意味着：
- 高并发下，即使单条查询只设
work_mem = '64MB'，100 个连接同时跑，就是 6.4GB 持久驻留内存 - 存储过程或函数内多次调用含 HASH JOIN 的子查询，
sp_head::main_mem_root（SQL Server）或 PG 的内存上下文可能不及时释放 - 连接池（如 pgbouncer）若配置
ignore_startup_parameters = 'work_mem'，SET LOCAL work_mem会被静默丢弃，你以为调了，其实没生效
真正难处理的从来不是“该不该调大内存”，而是“谁在用、用了多少、能不能提前砍掉一半”。一个没加索引的 JOIN 列，调到 128MB 也救不回来；但把 WHERE order_date >= '2025-01-01' 塞进子查询，可能让驱动表从 500 万行压到 3 万行——这时候 work_mem = '4MB' 都够用。
