Hash Match吃CPU因其需逐行哈希计算、内存不足时spill至磁盘引发IO与调度开销，且键值分布倾斜导致单线程过载。
哈希匹配（Hash Match）为什么吃CPU
哈希匹配本身不是错误，但它是SQL Server和PostgreSQL中典型的CPU密集型算子。当执行计划里出现Hash Match节点，且它占用了远高于其他算子的actual_cpu_time_ms（或SQL Server的cpu_time），基本可以断定这里是CPU飙升的源头。
它吃CPU的核心原因有三个：建哈希表要对每行连接键做哈希计算、内存不足时会spill到tempdb、键值分布倾斜会导致单线程处理过载。
- 哈希计算本身不轻——尤其当连接字段是
VARCHAR(200)或含NULL时，数据库得逐字节算哈希，还可能做隐式转换 - 一旦
Hash Match后面跟着Spill To TempDb（SQL Server）或Work-table: external merge（PostgreSQL），说明内存不够，开始反复读写磁盘临时文件，CPU在等IO的同时还在调度、压缩、解压，实际负载翻倍 - 如果连接键大量重复（比如
status = 'active'占95%行），哈希桶严重不均，一个线程干了80%的活，其他线程空转，top里看到单核100%、整体CPU却没跑满，就是这个征兆
怎么从执行计划确认是Hash Match惹的祸
别只看“有没有Hash Match”，要看它在计划里的位置、输入行数、是否spill、以及上游是否放大了数据量。
- 在SQL Server中，用
SET STATISTICS XML ON跑SQL，打开执行计划XML，搜索<relop logicalop="Hash Match">，重点看<code>EstimateRows和ActualRows是否差10倍以上——说明统计信息不准，优化器低估了哈希开销 - 查
sys.dm_exec_query_profiles（需启用QUERYTRACEON 7412），找physical_operator_name = 'Hash Match'那行，对比row_count和cpu_time_ms，若CPU耗时/行数 > 0.1ms，就属于高开销 - PostgreSQL里用
EXPLAIN (ANALYZE, BUFFERS)，看到Hash Cond同时带Buffers: shared hit=xxx read=yyy且Temp: read=zzz write=www，说明已落盘，必须调work_mem或换连接方式
Hash Match能避免吗？什么情况下该强制改写
不能一概而论“禁用Hash Match”，但某些场景下它纯属低效选择，强行保留只会浪费CPU。
- 小表驱动大表的等值连接（比如
JOIN config_codes c ON o.status_id = c.id，其中config_codes只有几十行），Nested Loops更合适——加索引后，CPU开销常降90% - 连接键存在大量NULL或固定值（如日志表中
tenant_id IS NULL占比高），哈希效率崩塌，此时拆出NULL分支单独处理，再UNION ALL，比硬扛一个Hash Match更省CPU - SQL Server中，如果两个表都有
user_id上的B树索引，且数据量适中（百万级以内），加OPTION (LOOP JOIN)强制走嵌套循环，有时比默认选的Hash Match快得多——前提是外层结果集确实小
容易被忽略的隐性放大点
很多人盯着Hash Match本身调优，却漏掉了让它变重的上游操作。
-
Compute Scalar出现在Hash Match之前，且表达式含ISNULL()或CASE WHEN，等于给每一行都多加一次CPU计算，再喂给哈希——先干掉这个标量计算，Hash Match的输入行可能直接少一半 -
Sort紧挨着Hash Match（常见于GROUP BY + JOIN混合查询），说明数据库先花CPU排序，再花CPU建哈希表——这时候优先考虑覆盖索引消除Sort，比调work_mem更治本 - 连接条件写了
ON a.x = b.y COLLATE SQL_Latin1_General_CP1_CI_AS这种显式排序规则，会导致每次比较都触发字符串归一化，哈希键计算成本指数上升——统一字段排序规则，比在SQL里硬加COLLATE靠谱得多
