很多开发者在SQL Server中尝试使用MERGE JOIN提示来强制优化器选择合并连接，但实际效果常常令人困惑——即便添加了提示，执行计划依然倾向于Hash连接或嵌套循环连接。提示似乎毫无作用，有时甚至语法检查完全通过，优化器仍然选择了其他连接算法。
核心原因在于：OPTION (MERGE JOIN)从来不是一条强制指令，而是一个“请优先考虑”的建议。优化器只有在满足了所有必要条件之后，才会认真评估这个建议。
为什么 MERGE JOIN 提示经常无效？
SQL Server的优化器本质上是一个理性且极度务实的决策引擎。它只有在同时确认以下所有条件成立时，才会采纳MERGE JOIN提示：
- 两个参与连接的数据源（表或中间结果集），在连接列上都具备已排序的输入。最常见的情况是相应列上存在索引，或者上游查询中包含了显式的
ORDER BY。 - 连接条件必须是等值连接，即使用
=运算符。非等值连接（如<>、>）与Merge Join的运行机制不兼容，提示会被直接忽略。 - 连接列的数据类型完全一致且不存在隐式转换。一个常见的陷阱是
varchar与nvarchar混用——这会破坏排序保证，优化器认为数据不可靠，从而放弃该方案。 - 统计信息没有严重过期。如果统计信息过时，优化器可能会误判排序的可行性，进而拒绝采用Merge Join。
上述条件只要任意一条不满足，SQL Server就会默默忽略你的提示，转而选择Hash Join或Loop Join。即使查看执行计划，也找不到Merge算子的任何踪迹。
如何让 MERGE JOIN 提示真正生效？
关键不在于如何“添加提示”，而在于如何为Merge Join准备好有序的输入数据。根据实践经验，以下几点最为重要：
- 确保连接列上都建立了合适的索引。例如，在
ON t1.id = t2.id上进行连接时，t1(id)和t2(id)最好都有单列升序索引，或者作为复合索引的引导列。 - 避免在连接列上使用任何函数或表达式。像
UPPER(t1.name) = UPPER(t2.name)这样的写法，即使两个字段都有索引，优化器也无法利用有序输入。 - 考虑在派生表或CTE中显式添加
ORDER BY。不过这是一把双刃剑——引入排序会增加额外开销，未必比Hash Join更高效。 - 检查执行计划中两个输入的“Ordered”属性是否显示为True。在图形化执行计划中，将鼠标悬停在算子上的属性窗口里可以看到这个关键信息——如果显示False，说明你的有序输入并未被验证。
一个典型的有效写法如下：
SELECT * FROM orders o INNER JOIN customers c ON o.customer_id = c.customer_id OPTION (MERGE JOIN);
注意，这段代码能触发Merge Join的前提是orders(customer_id)和customers(customer_id)都拥有B-tree索引，并且没有被WHERE子句中不可SARGable的条件影响使用。
MERGE JOIN 真正适用的场景是什么？
Merge Join的优势在于流式处理、低内存开销以及可中断性，但这些特性高度依赖于数据分布。哪些场景真正适合使用它？
- 适合两个大表之间的等值连接，并且两个表在连接键上已经处于物理排序状态——例如历史分区表按日期归档后重建过聚集索引。
- 不适合连接键大量重复的场景。如果键值重复过多，Merge Join会退化为嵌套循环模式，性能急剧下降。
- 如果连接键的基数极低（例如只有三五个不同值），Hash Join通常速度更快。此时强行添加
MERGE JOIN提示反而会成为负优化。 - 在并发环境下，Merge Join不需要像Hash Join那样争抢内存授权，因此表现更稳定。这一点在调优高并发系统时往往能带来意想不到的收益。
提示无效时，更务实的调整策略
与其在MERGE JOIN提示上固执地尝试，不如从以下几个方向着手：
- 使用
SET STATISTICS XML ON获取实际执行计划，仔细分析瓶颈是否真的在连接算法上——很多时候问题的根源并不在此。 - 检查连接列上是否有缺失索引。SQL Server提供的索引缺失DMV（
sys.dm_db_missing_index_details）比硬加提示更加可靠。 - 尝试将查询重写为
EXISTS配合索引覆盖扫描。有时这种写法能带来出乎意料的效果。 - 如果中间结果来自临时表，务必在连接列上
CREATE INDEX。没有索引，任何连接提示都是徒劳。
归根结底，决定Merge Join是否生效的，从来不是提示本身，而是你是否为它铺设好了两条并行且有序的“铁轨”。索引到位，一切水到渠成；索引欠妥，提示不过是一纸空文。
