SQL Server优化器通常选择最优JOIN算法，手动指定LOOP/HASH/MERGE提示属高风险干预；LOOP仅支持INNER/LEFT/RIGHT JOIN，FULL OUTER LOOP JOIN报错；REMOTE限INNER JOIN且右表须为远程表；MERGE要求联接字段已排序；语法须紧贴JOIN关键字。
SQL Server 优化器在绝大多数情况下选的 JOIN 算法是合理的，手动加 LOOP、HASH 或 MERGE 提示不是“更可控”，而是高风险干预——只有当执行计划反复出错、且你已排除统计信息不准、索引缺失、参数嗅探等常见原因后，才值得尝试。
哪些 JOIN 类型能配哪些 Hint？语法和限制必须对得上
不是所有组合都合法。SQL Server 会直接报错，而不是静默降级：
-
LOOP只允许用于INNER JOIN和LEFT/RIGHT OUTER JOIN；写FULL OUTER LOOP JOIN会触发错误Msg 137, Level 15 -
REMOTE仅限INNER JOIN，且右表必须是链接服务器上的远程表，左表行数还得明显更少，否则提示无效甚至拖慢查询 -
MERGE要求两表联接字段都有排序（如聚集索引或显式ORDER BY），否则运行时报错Cannot execute a MERGE JOIN on unsorted inputs - 语法必须紧贴
JOIN关键字：t1 INNER LOOP JOIN t2合法，t1 INNER JOIN t2 OPTION (LOOP JOIN)是错的（那是查询级提示，不作用于单对表）
LOOP vs HASH vs MERGE：什么场景真该换？别凭直觉
性能差异取决于数据分布和访问模式，不是“小表就该 LOOP”这种经验能覆盖的：
- 用
INNER LOOP JOIN的典型场景：驱动表极小（ - 用
INNER HASH JOIN的典型场景：两表都大、联接字段无索引、但内存充足；注意若内存不足，HASH 会退化成多轮溢出写磁盘，比 LOOP 更慢 - 用
INNER MERGE JOIN的典型场景：两表按联接字段天然有序（比如都是按id聚集），但优化器因统计信息滞后没选它；一旦字段有重复值过多，MERGE 的归并成本会陡增 - 长字符串（如
NVARCHAR(400)）联接时，HASH通常比LOOP更稳——因为 LOOP 需对每行做 N 次索引查找，而 HASH 只需一次哈希计算 + 一次桶匹配
加 Hint 前必须验证的三件事
跳过任何一项，Hint 很可能从“救急”变成“埋雷”：
- 先跑
SET STATISTICS XML ON，看当前执行计划里实际用了哪种 JOIN，确认是不是真选错了，而不是你以为错了 - 查
sys.dm_db_stats_properties，确保联接字段的统计信息是近期更新的（last_updated在 24 小时内），否则 Hint 解决的是假问题 - 用
DBCC SHOW_STATISTICS看直方图，确认优化器估算的行数（estimated_rows）和实际返回行数（actual_rows）偏差不大；如果差一个数量级，Hint 也救不了——得先解决统计失真
最常被忽略的一点：Hint 会锁死执行路径。哪怕半年后数据量翻十倍、索引结构变更、SQL Server 版本升级，只要语句没改，Hint 就继续强制旧策略。它不感知环境变化，只忠于你当初那行字面指令。
