Hash JOIN易OOM主因是SQL Server默认将整个构建端表载入内存建哈希表，遇大宽表或并行时内存陡增，且hash warning仅在溢出tempdb时触发，此前已可能被系统杀掉。
为什么Hash JOIN在SQL Server里容易OOM
不是Hash JOIN算法本身设计有问题，而是它默认尝试把整个“构建端”（build input）表载入内存建哈希表——如果这张表有千万行、每行带TEXT或多个VARCHAR(2000)，单次加载就可能吃掉几GB内存。更关键的是：SQL Server的hash warning事件只在溢出到tempdb时才触发，而在此之前，内存已持续增长，直到被Windows内存管理器杀掉进程或触发RESOURCE_SEMAPHORE等待。
先确认是不是真由Hash JOIN导致OOM
别一看到慢或断连就调内存。必须用实际执行计划验证：
- 查
sys.dm_exec_query_stats+sys.dm_exec_sql_text，找last_dop > 1且last_grant_kb异常高的语句 - 在SSMS中启用
SET STATISTICS XML ON，看执行计划里是否有<RelOp NodeId="X" PhysicalOp="Hash Match">，并检查EstimateRows是否比实际大几个数量级 - 运行时捕获
hash warning事件：用Extended Events监听query_post_execution_showplan或hash_warning，出现即说明已spill
避免盲目调大max server memory
max server memory是全局上限，调高不能解决Hash JOIN局部内存陡增问题，反而挤压buffer pool，加剧PAGEIOLATCH_SH争用。真正该动的是查询级资源控制：
- 对已知大表JOIN加
OPTION (HASH JOIN, MAXDOP 1)强制单线程+哈希，避免并行线程各自建哈希表重复消耗 - 用
OPTION (RECOMPILE, OPTIMIZE FOR (@var = N'xxx'))让优化器基于真实参数重估行数，防止因统计信息陈旧误判为小表而选错算法 - 对热点key（如status='active'）提前过滤：
WHERE t1.status = 'active' AND t2.status = 'active'，比在JOIN后HAVING或WHERE外层过滤更早削减输入行数
当数据倾斜严重时，拆分处理比硬扛更有效
Hash JOIN最怕key分布不均——比如1%的user_id占了90%的订单行。这时即使总内存够，单个线程哈希表也会爆。可行做法：
- 先把倾斜key单独拎出来：
SELECT * FROM orders WHERE user_id IN (SELECT user_id FROM users WHERE is_hot = 1)，走索引+NLJ - 剩余数据再走Hash JOIN：
SELECT ... FROM orders o INNER JOIN users u ON o.user_id = u.id WHERE u.is_hot = 0 - 最后
UNION ALL合并结果——注意别用UNION，去重开销更大 - 若无法改SQL，可在应用层按user_id范围分片查询，比如
user_id BETWEEN 1 AND 100000，每次查完清空本地缓存
Hash JOIN的内存压力本质是“构建端数据量 × 行宽 × 并行度”的乘积，任何一维失控都会引发OOM。比起堆内存，优先检查统计信息是否更新、关联字段类型是否隐式转换、tempdb是否位于高速磁盘——这些细节比调max server memory管用得多。
