应仅在确认当前执行计划低效、两表关联列无有效索引、数据量大且内存充足时，才使用OPTION (HASH JOIN)；它适用于大表join小表或两表都大但无排序需求的场景，写法须置于SELECT/UPDATE/DELETE语句末尾紧邻分号前，且不跨CTE或子查询生效。
什么时候该用 OPTION (HASH JOIN) 提示
只有当你确认当前执行计划里用了低效的 Nested Loop 或 Merge Join，且两表关联列无有效索引、数据量大、内存充足时，才考虑强制用 Hash Join。它适合“大表 join 小表”或“两表都大但无排序需求”的场景；如果小表有唯一索引且连接列高度选择性，Nested Loop 反而更快。
OPTION (HASH JOIN) 的写法和生效范围
提示必须放在查询末尾，紧贴 ;（如果有）之前，且只对**紧邻的 SELECT/UPDATE/DELETE 语句**生效，不能跨 CTE 或子查询传播：
SELECT a.id, b.name FROM orders a INNER JOIN customers b ON a.customer_id = b.id OPTION (HASH JOIN);
常见错误包括：
- 把提示写在 CTE 定义里（如
WITH cte AS (...) SELECT ... OPTION (HASH JOIN)），实际只影响外层 SELECT，CTE 内部仍走原计划 - 在视图定义中加提示——SQL Server 忽略视图内的查询提示
- 同时指定多个 join 提示（如
OPTION (HASH JOIN, LOOP JOIN)），SQL Server 报错Msg 8622
Hash Join 提示失败的典型报错和原因
最常遇到的是 Msg 8622: Query not allowed to execute due to optimizer cost threshold，说明优化器认为强制 Hash Join 的代价高于阈值。这不是配置问题，而是 SQL Server 拒绝执行明显低效的物理操作：
- 连接列存在 NULL 值且未被过滤：Hash Join 对 NULL 处理严格，若
ON条件列含大量 NULL，优化器可能直接拒绝 - 参与 join 的某一侧是远程表（如四部分命名的 linked server 表），SQL Server 不支持对其强制 Hash Join
- 查询含不兼容操作符，比如
LIKE '%abc'导致无法生成哈希键，提示会被忽略 - 数据库兼容级别低于 120（SQL Server 2014），部分提示行为受限
比 OPTION (HASH JOIN) 更稳妥的替代方案
硬编码提示容易在数据分布变化后反成性能瓶颈。优先考虑：
- 给连接列补上合适索引（尤其是覆盖索引），让优化器自己选 Hash Join
- 用
UPDATE STATISTICS刷新统计信息，避免因过期统计导致误判 - 临时启用跟踪标志
TF 8649（需 sysadmin 权限），允许优化器考虑并行 Hash Join 路径，比单条提示更可控 - 拆分复杂查询：把多表 join 拆成中间结果集（如用
#temp表承载小表），再 join 主表，往往比强行提示更稳定
真正难搞的不是怎么写提示，而是判断“此刻是否真需要它”——多数情况下，执行计划变慢是因为统计信息不准或索引缺失，而不是 join 算法本身错了。
