HASH JOIN哈希溢出主因是优化器行数估算严重失准，而非总内存不足；具体源于统计信息过期、JOIN字段类型不一致或WHERE条件未下推，导致构建表全量加载内存后溢出至tempdb或磁盘。
HASH JOIN 出现哈希溢出，不是因为服务器总内存不够，而是 SQL Server（或 PostgreSQL）在执行时，把整个“构建表”（通常是右表）全量加载进内存建哈希表，结果发现实际数据远超优化器预估——内存撑不住，只能往 tempdb（SQL Server）或磁盘临时文件（PostgreSQL）里写，这就是哈希溢出。
HASH JOIN 溢出的直接诱因是估算严重失准
优化器靠统计信息预估行数，一旦失准，分配的内存就错得离谱：
-
统计信息过期：比如SELECT COUNT(*) FROM orders WHERE user_id = 12345实际返回 3 行，但统计显示 3000 行，优化器误判为“大结果集”，强行选HASH JOIN -
JOIN字段类型不一致：如INT对BIGINT或VARCHAR(50)对VARCHAR(100)，触发隐式转换，索引失效，统计路径断裂 -
WHERE条件没下推：写成FROM orders o JOIN users u ON o.user_id = u.id WHERE o.order_date >= '2025-01-01'，而非把过滤塞进子查询，导致百万行全量参与哈希构建
怎么一眼看出已经溢出？
别等报错，执行中就能确认：
- 执行计划里
Hash Match算子属性中SpillLevel > 0或带警告Operator used tempdb - 运行时查
sys.dm_db_session_space_usage（SQL Server）：若internal_objects_alloc_page_count骤增，说明正在往tempdb写哈希页 - PostgreSQL 查
EXPLAIN (ANALYZE, BUFFERS)：Hash节点下出现disk: N kB，或pg_stat_progress_hash显示hash_probe_total_buckets远大于hash_buckets_used
为什么加了索引、调了 work_mem 还溢出？
因为很多“调参”动作没打到根上：
-
work_mem（PostgreSQL）或查询内存授予（SQL Server）只管单个哈希操作，但一个查询可能含多个HASH JOIN+SORT，总内存是叠加的 - 并行执行时，每个 worker 都独占一份
work_mem，max_parallel_workers_per_gather = 4就可能吃掉 4 倍额度 - 索引存在但顺序不一致（如一边
ASC、一边DESC），MERGE JOIN无法启用，优化器仍 fallback 到HASH JOIN -
FORCE ORDER锁死连接顺序后，又硬加MERGE JOIN提示，反而破坏双排序前提，提示失效
真正卡住的，往往是估算链路上某个断裂点——比如视图里藏着未更新的统计，或 CTE 隐藏了真实基数。这类问题不会出现在错误信息里，但会在 granted_memory_kb 和 used_memory_kb 的差值里暴露：如果 used 接近甚至超过 granted，说明优化器给的预算本身就错了。
