sql server中强制子查询走hash join的关键是use hint('force_hash_join')，而非option(hash join)；该提示仅对等值连接有效，且依赖子查询成功展开为物理连接操作。
SQL Server里强制子查询走Hash Join的关键是USE HINT，不是JOIN HINT
很多人以为得在INNER JOIN或LEFT JOIN附近加OPTION (HASH JOIN)，但子查询（尤其是非相关子查询、EXISTS/IN子句）本身不显式写JOIN，这时候HASH JOIN提示根本不会生效。真正起作用的是语句级的USE HINT，它能影响优化器对整个连接策略的选择。
典型错误写法：SELECT * FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id) OPTION (HASH JOIN) —— 这个HASH JOIN会被忽略，因为没指定连接对象。
-
USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_150')这类兼容性提示不影响连接算法 - 必须用
USE HINT('FORCE_HASH_JOIN')，这是SQL Server 2016 SP1+才支持的正式Hint - 该Hint作用于整个查询计划中所有适用的连接（包括子查询展开后的内部连接）
- 仅对等值连接（
=）有效；含LIKE、范围条件的连接无法强制Hash
子查询被展开后才能被FORCE_HASH_JOIN影响
SQL Server优化器会先把IN、EXISTS、NOT EXISTS等子查询尝试“展开”（apply-to-join transformation），变成INNER JOIN或LEFT ANTI SEMI JOIN等物理操作。只有展开成功，USE HINT('FORCE_HASH_JOIN')才有目标可作用。
- 相关子查询如果含聚合或TOP，可能无法展开，Hint失效
-
IN (SELECT ...)比EXISTS (SELECT ...)更容易被展开为INNER JOIN - 检查执行计划XML，搜索
RelOp NodeId="X" PhysicalOp="Hash Match"确认是否命中 - 若看到
Nested Loops或Merge Join仍存在，说明Hint未生效，需查展开是否失败
FORCE_HASH_JOIN和OPTION(HASH JOIN)混用会冲突
如果同时写了OPTION (HASH JOIN)和USE HINT('FORCE_HASH_JOIN')，SQL Server优先按OPTION处理，但OPTION (HASH JOIN)本身在子查询场景下语法不合法，会导致报错Msg 8622, Level 16：“查询优化器无法生成计划”。这时候反而要删掉OPTION，只留USE HINT。
- 正确写法：
SELECT * FROM t1 WHERE t1.id IN (SELECT id FROM t2) OPTION (USE HINT('FORCE_HASH_JOIN')) - 错误写法：
... OPTION (HASH JOIN, USE HINT('FORCE_HASH_JOIN'))——HASH JOIN参数不被接受 - 如果子查询用了
GROUP BY，加FORCE_HASH_JOIN可能让优化器放弃并行，性能反而下降 - 该Hint不保证100% Hash Match：当内存不足或统计信息严重过期时，仍可能回退到Nested Loops
验证是否真走了Hash Join，别只看图标
SSMS图形执行计划里“Hash Match”图标容易误判——它可能是Hash Aggregate、Hash Warning，也可能是Hash Join。必须点开属性看PhysicalOp字段值，并确认LogicalOp是Inner Join、Left Semi Join或Right Anti Semi Join。
- 关键字段组合：
PhysicalOp="Hash Match"+LogicalOp="Inner Join" - 若
EstimateRows和ActualRows差10倍以上，说明统计信息不准，Hash效率可能极低 - 留意
Warnings属性：出现Hash Warning: No memory grant意味着Hash溢出到tempdb，IO飙升 - 子查询走Hash的前提是驱动表（外侧）行数少、被驱动表（内侧）有合适索引或全表扫描成本可控
最常被忽略的一点：FORCE_HASH_JOIN只改变连接算法，不解决数据倾斜。如果子查询返回大量重复键值，Hash Match会严重拖慢，这时候得先在子查询里加DISTINCT或改用临时表预聚合。
