必须用t1 INNER LOOP JOIN t2写法，不能用OPTION (LOOP JOIN)；后者强制全语句所有JOIN走嵌套循环，易触发错误8622或性能雪崩，且LOOP仅支持INNER/LEFT/RIGHT OUTER JOIN，不支持FULL OUTER。
INNER LOOP JOIN 写法必须紧贴 JOIN 关键字
SQL Server 不接受 OPTION (LOOP JOIN) 这类语句级提示来指定某一对表的连接方式——它会强制整条查询里所有 JOIN 都走嵌套循环，极易触发错误 8622（优化器无法生成计划），或让大表连接慢到不可接受。
真正生效的写法是把算法提示直接写在 JOIN 关键字前面，且必须明确连接类型：
-
t1 INNER LOOP JOIN t2✅ 正确：只影响这一对表 -
t1 INNER JOIN t2 OPTION (LOOP JOIN)❌ 错误：语法上不报错，但提示被忽略 -
t1 LEFT LOOP JOIN t2✅ 支持：LOOP 允许 LEFT/RIGHT OUTER JOIN -
t1 FULL LOOP JOIN t2❌ 报错：Msg 137，FULL OUTER 不支持 LOOP
HASH 和 MERGE 提示同样要写在 JOIN 前，不能靠 OPTION
OPTION (HASH JOIN) 是全局开关，不是局部控制。它和 OPTION (LOOP JOIN) 一样，会拉爆整条查询的执行计划，尤其当其中某对表本该走 MERGE 或 LOOP 时。
要精准干预某次连接，必须用表级写法：
-
t1 INNER HASH JOIN t2：驱动表无需特别小，但要求内存足够、连接字段等值、无高重复率 -
t1 INNER MERGE JOIN t2：两表必须已按连接字段有序——聚集索引扫描（Clustered Index Scan）可满足，非聚集索引 + 无ORDER BY则不行 - 长字符串（如
NVARCHAR(400)）连接时，MERGE JOIN易因重复值卡顿，HASH JOIN更稳
USE_NL / USE_HASH 等 Oracle 风格 Hint 在 SQL Server 中完全无效
SQL Server 不识别 /*+ USE_NL(t2) */ 这类注释型 Hint。它会直接跳过，执行计划里照样出现 HASH JOIN 或 MERGE JOIN。
替代方案只有两个：
- 改用
INNER LOOP JOIN等原生写法，明确指定这一对表 - 配合
OPTION (FORCE ORDER)控制 JOIN 顺序，再靠索引引导物理访问路径——但代价是关闭整个查询的 Join Reordering，数据量突变时风险很高
注意：LEADING、USE_NL 这些是 Oracle 专属语法，在 SQL Server 里写了等于没写。
加了提示不等于真生效，必须看执行计划里的实际操作符
常见假成功现象：语法没报错，执行计划里却看不到 NESTED LOOPS、HASH MATCH 或 MERGE JOIN 字样，只看到 Hash Cond 或 Join Filter——说明提示未被采纳。
验证三件事：
- 当前 SQL Server 版本是否支持该提示（例如旧版不支持
REMOTE） - 执行计划 XML 或图形化界面中，对应连接节点的操作符是否确实是目标类型
- 驱动表是否真的小、内表连接列是否有可用索引（否则
LOOP JOIN会退化成大量随机 I/O）
最容易被忽略的是：提示只解决“怎么连”，不解决“连得对不对”。如果连接字段没索引、统计信息过期、或者连接条件本身无法利用索引，再准的 Hint 也救不了性能。
