为何SQL Server 2019中HASH JOIN会导致服务器CPU飙高？

Hash Join 的 CPU 瓶颈源于场景错配：右表千万级无过滤时哈希构建耗时占比超90%，需通过 Actual CPU Time/Actual Rows 比值（>0.1ms）、统计信息过期、tempdb 溢出、哈希倾斜及 UPDATE 场景默认选择等问题综合诊断与优化。

不是 HASH JOIN 本身有问题，而是当它被用在不适合的场景时，CPU 集中消耗在哈希表构建阶段——尤其右表千万级、无过滤、无索引时，cpu_time 占语句总耗时 90% 以上。

Hash Match 节点出现在执行计划里就等于 CPU 热点

别只看有没有 Hash Match，重点看它是不是执行计划里最“胖”的节点：在 SSMS 图形计划中右键 → “Properties”，检查 Actual CPU Time 和 Actual Rows 的比值。若单行平均耗时 > 0.1ms，基本可断定是瓶颈。

• EstimateRows 和 ActualRows 相差 10 倍以上？说明统计信息过期，优化器误判了数据规模，强行选了 Hash
• 看到 Warning: Operator used tempdb 或 XML 计划里有 SpillToTempDb？说明内存不足，哈希表溢出到磁盘，CPU 在等 IO 的同时还在调度压缩/解压
• 连接键大量重复（比如 tenant_id IS NULL 占 95%）？哈希桶严重倾斜，一个线程干了全部活，top 显示单核 100%，整体 CPU 却没跑满

UPDATE ... FROM 关联大表时 Hash Join 是默认陷阱

SQL Server 在 UPDATE t1 SET x = y FROM t1 JOIN t2 ON ... 这类写法中，只要左表预估行数较大（比如匹配 50 万行），即使右表有索引，优化器也倾向选 Hash Join——因为理论上 O(n+m) 比 Nested Loops 的 O(n×m) 更优，但现实是哈希计算 + 内存重分配远比多次 Index Seek 更吃 CPU。

• 真正有效的缓解不是“禁用 Hash Join”，而是让优化器愿意走 Nested Loops：给 t1 加 (WHERE 条件列, JOIN 列) 复合索引，给 t2 加仅含连接列的窄索引（如 CREATE INDEX IX_t2_tid ON t2(t1_id)）
• UPDATE STATISTICS t1 WITH FULLSCAN 和 UPDATE STATISTICS t2 WITH FULLSCAN 必须做——否则优化器基于陈旧统计信息估算的行数会严重失真
• 避免在 ON 子句里用函数（如 UPPER(a.id) = UPPER(b.id)），这会让索引失效，直接触发全表扫描驱动的 Nested Loops，反而更糟

Hash Join 的内存和并行度失控才是隐形推手

SQL Server 默认按“小表建哈希表”分配内存，但这个“小”是基于统计信息预估的。一旦预估错误，或并行度（MAXDOP）设得过高，多个线程同时争抢哈希桶、反复重哈希、竞争内存页，CPU 就会毛刺式飙升。

• 查当前语句是否受参数嗅探影响：SELECT * FROM sys.dm_exec_query_stats WHERE sql_handle = ... 看 plan_generation_num > 1，说明同一 SQL 因参数不同反复生成新计划
• 临时压制并行：在语句末尾加 OPTION (MAXDOP 1)，观察 CPU 是否平稳——如果明显下降，说明原计划被过度并行反噬
• 不建议全局调低 cost threshold for parallelism，容易把本该并行的小查询拖慢；优先从单条语句的索引+统计信息入手

最常被跳过的动作是更新统计信息——哪怕索引建得再准，UPDATE STATISTICS 没跑，优化器还是在瞎猜。而一旦哈希表开始往 tempdb 溢出，CPU 开销就不再是纯计算问题，而是 IO 调度+内存管理+哈希冲突三重叠加。