标量子查询易触发Hash Match溢出，典型场景包括SELECT列表中相关子查询或WHERE中IN/EXISTS子句；当连接列无索引、统计信息过期或结果集基数估算偏低时，优化器强行选择Hash Match导致tempdb溢出，应通过补索引、下推过滤、改写为JOIN或OUTER APPLY来规避。
子查询触发Hash Match的典型场景
SQL Server对相关子查询（尤其是SELECT列表里的标量子查询或WHERE中的IN/EXISTS）并不总转成JOIN；只有当优化器估算成本更低、且子查询结果集基数较小时，才可能生成Hash Match或Nested Loops。但一旦子查询涉及大表、连接列无索引、或统计信息过期，优化器就容易低估行数，强行选Hash Match——这时它不是“快”，而是开始往tempdb里灌数据。
-
SELECT id, (SELECT name FROM users u WHERE u.id = o.user_id) FROM orders o：标量子查询，每行orders都执行一次，若users.id没索引，SQL Server可能为这个嵌套循环建哈希表缓存中间结果，反而引发spill -
WHERE order_id IN (SELECT order_id FROM audit_log WHERE created >= '2026-01-01')：若audit_log千万级且created无索引，IN子查询易被转成Hash Match Semi Join，但估算行数偏低时直接溢出到tempdb -
NOT IN (SELECT ...)：只要子查询列允许NULL，整个逻辑就失效，优化器大概率放弃半连接优化，退化成低效的Filter + Nested Loops或更糟的Hash Match
怎么判断子查询是否真走Hash Match
别猜，看执行计划。打开SET STATISTICS XML ON，跑查询后在SSMS里点“显示执行计划”，重点找：Hash Match节点是否带SpillLevel > 0属性；右键该节点→“属性”→查Warning字段是否含Operator used tempdb；或者运行时查sys.dm_db_session_space_usage，看internal_objects_alloc_page_count是否突增。
注意：sys.dm_exec_query_plan只能看到算子类型，看不到spill详情；EXPLAIN在SQL Server里叫SET SHOWPLAN_XML ON，但它不执行，所以无法捕获真实spill行为——必须实际执行+开统计才能确认。
避免Hash Match溢出的实操手段
核心不是禁用Hash Match，而是让优化器有更好选择，或控制它的“胃口”。
- 给子查询里的连接/过滤列补索引：比如
audit_log(created, order_id)覆盖索引，能让IN子查询走Index Seek而非全表扫描，优化器自然倾向Nested Loops - 把WHERE条件下推进子查询：写成
WHERE order_id IN (SELECT order_id FROM audit_log WHERE created >= '2026-01-01' AND order_id IS NOT NULL)，而不是在外层再过滤——减少参与哈希构建的行数 - 用
EXISTS替代IN时要小心：SQL Server对EXISTS默认保留嵌套循环，除非你加OPTION (HASH JOIN)提示；但盲目加提示可能适得其反，先看执行计划再决定 - 对超大子查询结果，考虑用临时表+索引：比如先把
SELECT order_id INTO #tmp_audit FROM audit_log WHERE created >= '2026-01-01'，再CREATE INDEX IX_tmp ON #tmp_audit(order_id)，最后JOIN或IN——比让优化器硬扛一个没索引的大结果集靠谱得多
标量子查询为什么特别容易出问题
PostgreSQL和SQL Server都把相关标量子查询当作“每行调用一次”的黑盒，执行器只能走Nested Loops。如果外层表orders有10万行，子查询哪怕平均0.5ms，总耗时也逼近50秒——这时优化器可能试图缓存子查询结果，用Hash Match Aggregate预计算，但一旦缓存失败或估算错，就变成双重开销：既慢，又吃tempdb。
真正省事的做法是重写：把SELECT id, (SELECT name FROM users WHERE id = o.user_id) FROM orders o改成SELECT o.id, u.name FROM orders o LEFT JOIN users u ON o.user_id = u.id。JOIN能用索引驱动，执行计划可控，且避免了标量上下文带来的隐式聚合风险。
复杂点在于，有些业务逻辑天然依赖标量子查询的语义（比如COALESCE((SELECT ...), 'default')），这时候不能简单替换，得结合OUTER APPLY或CTE预计算——但无论如何，别让它在百万行上裸跑。
