MERGE JOIN本身不排序，只做双指针归并；真正耗资源的是优化器被迫插入的Sort节点，需确保子节点为Clustered Index Seek或Index Scan且Ordered="true"，并避免ON条件计算、类型转换、WHERE失序及聚合破坏有序性。
MERGE JOIN 本身不排序，但输入流必须有序
MERGE JOIN 算法不包含排序逻辑——它只做双指针归并。所谓“需要排序”，其实是优化器发现任一输入流未按 ON 字段物理有序时，被迫在执行计划里插入 Sort 节点。这个 Sort 才是真正吃 CPU 和内存的元凶。
常见错误现象：
- 执行计划里
Merge Join节点底下挂着Sort（尤其带黄色叹号） -
ActualRows比EstimatedRows高 5 倍以上，说明统计信息不准，优化器误判了有序性 - 明明建了索引，但子节点是
Index Scan却没Ordered="true"属性
怎么让输入流真正“有序”？不是建索引就完事
索引只是达成有序的手段之一，关键看执行计划中子节点是否满足两个硬条件：
- 子节点必须是
Clustered Index Seek或Index Scan（不能是Seq Scan或Sort） - 每个子节点 XML 属性里必须有
Ordered="true" - 索引定义顺序必须严格匹配
ON字段顺序：比如ON a.x = b.y，那a表需有INDEX ix_a_x ON a(x)，b表需有INDEX ix_b_y ON b(y) - 非聚簇索引也行，但必须以联接列为最左前缀，且不能被查询破坏（如
WHERE UPPER(x) = 'ABC'）
哪些写法会悄悄触发 Sort？
哪怕索引和统计都对，以下操作仍会让优化器放弃有序流：
- 在
ON条件里做计算：ON UPPER(a.name) = UPPER(b.name)、ON ISNULL(a.id, 0) = b.id - 隐式类型转换：
ON a.user_id = b.code（a.user_id是INT，b.code是VARCHAR） -
WHERE条件没命中索引最左前缀：有INDEX(status, created_at)，却写WHERE created_at > '2025-01-01' - 加
TOP、OFFSET或FOR XML，优化器可能认为“排序流不可靠”，直接退化为Hash Join
为什么聚合后 MERGE JOIN 容易失效？
GROUP BY 或 SELECT DISTINCT 后的结果集默认无序——即使源表按 user_id 聚簇，SELECT user_id, SUM(amount) FROM orders GROUP BY user_id 的输出也不保证 user_id 有序，除非显式加 ORDER BY user_id。
此时再 JOIN 其他表，优化器看到左表无序，右表虽有序，但无法归并，就会跳过 Merge Join。更麻烦的是：聚合结果没有自动统计信息，优化器只能瞎猜行数和分布，容易误选算法。
实操建议：
- 把聚合结果物化为临时表，再对其执行
UPDATE STATISTICS - 在聚合字段（如
user_id）上单独建统计信息，比依赖全表抽样准得多 - 避免用视图封装聚合逻辑——视图不存统计信息
真正卡住性能的，从来不是 MERGE JOIN 这个名字，而是优化器看到的“数据长相”。而统计信息，就是它唯一能读的说明书——漏掉一行更新，整个计划就可能跑偏。
