SQL Server强制JOIN算法必须用INNER LOOP/HASH/MERGE JOIN语法，置于JOIN关键字前且仅对相邻表生效；顺序错误、位置错误或缺失INNER将导致失效或语义改变。
SQL Server里强制INNER JOIN用LOOP/HASH/MERGE，必须写对语法位置
SQL Server不支持Oracle那种/*+ USE_NL(t2) */风格的注释式Hint，它的Join Hint是直接嵌在JOIN关键字前的修饰词，且只对紧邻的那一对表生效。写错位置——比如塞进WHERE里、或放在SELECT后面——Hint就彻底被忽略。
正确写法只有这一种模式：INNER LOOP JOIN、INNER HASH JOIN、INNER MERGE JOIN，三者必须完整出现，顺序不能颠倒。例如：
SELECT * FROM Sales.Orders o INNER HASH JOIN Sales.OrderDetails od ON o.orderid = od.orderid
常见错误包括：
- 写成
INNER JOIN HASH（顺序错，SQL Server报错） - 漏掉
INNER，只写HASH JOIN（会被解析为LEFT HASH JOIN，语义全变） - 在多表JOIN中只给某一处加Hint，其余仍由优化器选——结果就是部分走Hash，部分走Nested Loop，执行计划割裂
LOOP JOIN不能配RIGHT或FULL，但INNER完全没问题
LOOP提示在SQL Server里明确禁止与RIGHT JOIN或FULL JOIN共用，否则直接报错Msg 137, Level 15。但它和INNER JOIN是天然兼容的，尤其适合驱动表小、内表连接列有高效索引的场景。
典型适用条件：
- 外表（驱动表）过滤后行数 WHERE status = 'shipped' AND created_date > '2026-09-01'
- 内表在JOIN列上有唯一索引或高选择性非聚集索引
- 连接条件全是等值，没有
BETWEEN或LIKE这类范围操作
反例：如果内表OrderDetails上orderid没索引，INNER LOOP JOIN会退化成对每行外表都做一次全表扫描，比HASH JOIN慢一个数量级。
加了Hint不等于生效，必须看实际执行计划里的Operator
写了INNER HASH JOIN，执行计划里却看到Nested Loops？不是Hint失效，就是你没验证对地方。SQL Server的执行计划XML或图形界面里，关键要看每个JOIN节点的PhysicalOp属性值，而不是只扫一眼“Join Type”文字。
确认生效的硬指标：
-
PhysicalOp="Hash Match"→HASH JOIN成功 -
PhysicalOp="Nested Loops"→LOOP JOIN成功 -
PhysicalOp="Merge Join"→MERGE JOIN成功
容易被误判的情况：
- 计划里出现
Hash Match (Aggregate)，但这跟JOIN无关，是GROUP BY触发的 - 用了
OPTION (RECOMPILE)但没清缓存，旧计划还在复用 - 数据库兼容级别低于120（SQL Server 2014），部分Hint不识别
REMOTE和REDISTRIBUTE这些冷门Hint，别乱碰
REMOTE只在跨服务器查询时有意义：左表本地、右表远程，且左表行数远小于右表时才可能提速。生产环境极少需要它，强行加上反而可能因网络延迟拖垮整体响应。
REDISTRIBUTE和REPLICATE属于并行数据分发策略，只在SQL Server并行度（MAXDOP）>1且数据量极大时起作用。普通OLTP查询加了不仅没收益，还会引发额外的数据重分布开销，导致CPU飙升。
真正该优先检查的，是JOIN列是否建了索引、统计信息是否过期、两表实际行数是否和EXPLAIN里显示的EstimatedRows接近——这些才是影响JOIN算法选择的根本原因，Hint只是最后的干预手段。
