SQL Server中JOIN提示仅在执行计划明显不合理且经XML统计确认时才需显式指定，属性能救火手段，非日常写法；常见场景包括小表误选Hash、大表与单行驱动表误选Merge、临时表缺统计信息等。
SQL Server中JOIN提示（如LOOP、HASH、MERGE）什么时候必须显式指定
SQL Server查询优化器绝大多数时候能自动选对连接算法，但当你看到执行计划里出现明显不合理的Hash Match或Nested Loops，且实际运行慢得反常时，才需要考虑加JOIN提示。这不是日常写法，而是性能救火手段。
常见触发场景包括：
-
INNER JOIN两边都是小表（Hash Match，导致内存开销大、延迟高 - 大表与极小驱动表（比如只查1条记录的
WHERE ID = @id）做LEFT JOIN，优化器误判为适合Merge Join，而实际Nested Loops才是最优 - 临时表没有统计信息，优化器基于空统计估算出错误的连接顺序和算法
注意：加提示前必须先用SET STATISTICS XML ON确认当前执行计划确实有问题，不能凭感觉加。
LOOP / HASH / MERGE三种JOIN提示的实际行为差异
LOOP（Nested Loops）本质是“外层每行，内层全扫一遍”，适合驱动表极小、被驱动表有索引的情况。例如：用单个OrderID查订单详情，Orders表只返回1行，OrderDetails上有OrderID索引——这时INNER LOOP JOIN比Hash快得多。
HASH会建哈希表，内存消耗大，但对无序大表连接更稳定。它不适合小结果集+高并发场景，容易引发hash warning或tempdb争用。
MERGE要求两表都按连接列排序（物理有序或有对应索引），否则会悄悄加Sort操作，反而拖慢。别看到“Merge”就以为快——如果没索引支撑，它可能比Loop还慢。
你不能只看算法名，得看数据分布和索引是否存在。比如MERGE JOIN在两个已按CustomerID聚簇的表之间最快，但若其中一张是SELECT ... INTO #tmp生成的临时表且没建索引，那MERGE就会失效。
使用JOIN提示时最容易踩的三个坑
- 提示写在
FROM子句里，但漏掉了ON条件位置：正确是FROM A INNER LOOP JOIN B ON A.id = B.id，不是FROM A INNER JOIN B LOOP ON ...——语法错直接报错 - 在视图或内联表值函数里加提示，结果被上层查询覆盖：SQL Server会忽略嵌套层级里的提示，只认最外层
FROM的提示 - 把提示当长期方案：一旦表数据量变化、索引重建或统计信息更新，原来最优的提示可能变成最差选择。生产环境上线前必须用真实数据量压测，不能只在开发库验证
提示不是银弹，它绕过了优化器的代价估算逻辑。你给的指令越强，优化器放弃自主判断的范围就越大——这在数据分布突变时反而更危险。
替代JOIN提示的更安全做法
优先检查并修复根本问题，而不是加提示：
- 确保连接字段上有有效索引，特别是
WHERE+JOIN共用的字段（如WHERE Status = 1 AND CustomerID = @cid，索引应为(Status, CustomerID)） - 对临时表手动更新统计信息：
UPDATE STATISTICS #tmp WITH FULLSCAN - 用
OPTION (RECOMPILE)让参数敏感查询每次重编译，避免参数嗅探导致的错误连接选择 - 拆分复杂多表JOIN，用CTE或临时表控制中间结果集大小，比硬塞一个
HASH提示更可控
真正该加提示的时刻极少——通常是线上突发慢查询、其他手段都试过且定位到就是连接算法错，再加。加完必须加注释说明原因和测试依据，否则半年后没人记得为什么这里非得LOOP。
