Merge Join CPU高是因为输入流未按联接字段物理有序，触发隐式Sort操作；需确保两表联接列均有匹配顺序的索引、查询不破坏排序前提（如无函数/类型转换）、统计信息最新，且执行计划中子节点Ordered="true"。
为什么 Merge Join 在 SQL Server 里一用就 CPU 高？
不是 Merge Join 本身慢，而是它被逼着“现场排序”——只要任一输入流没按联接字段物理有序，SQL Server 就会在执行计划里悄悄插一个 Sort 操作符。这个节点不显眼，但会吃掉大量 CPU，尤其在大结果集场景下。你看到执行计划里 Merge Join 节点带黄色叹号、底下跟着 Sort，基本就是它了。
关键点在于：Merge Join 不依赖索引存在，只认数据流是否 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'或x = 123但x是varchar） -
TOP、OFFSET、FOR XML等操作可能让优化器放弃使用已排序流，直接退化为Hash Join或加Sort
怎么确认 Merge Join 真正免排序了？
别信执行计划里写了 Merge Join 就万事大吉。得往下钻两层看子节点：
- 打开实际执行计划（
SET STATISTICS XML ON），找<RelOp LogicalOp="Merge Join">节点 - 检查它的两个子节点：必须都是
Index Scan或Clustered Index Seek，且属性Ordered="true" - 对比每个子节点的
EstimatedRows和ActualRows：如果差 10 倍以上（比如预估 500 行，实际 8 万行），说明统计信息过期，Merge Join可能已被迫降级 - 查
modification_counter：运行DBCC SHOW_STATISTICS('table_name', 'index_name')，若该值超过表总行数 20%，立刻执行UPDATE STATISTICS table_name WITH FULLSCAN
Merge Join 比 Hash Join 快的三个硬条件
别为了“看起来高级”硬推 Merge Join。它只在以下三者同时满足时才有优势：
- 两表都很大（比如各千万级以上），且联接字段天然有序（如日志表按
event_time聚簇、订单表按id自增主键） - 需要流式输出或早期终止（比如嵌套在
CROSS APPLY中，或外层有TOP 100）——Merge Join能边扫边出，Hash Join必须建完哈希表才吐第一行 - 内存吃紧：
Hash Join会申请大量内存建哈希表，Merge Join内存占用恒定（只缓存几行用于双指针归并）
反例很常见：小表 + 大表关联，Hash Join 通常更快；两表都无序，硬加索引只为凑 Merge Join，IO 和维护成本反而更高。
多列关联时 Merge Join 还能用吗？
能，但门槛更高。核心是：所有 ON 字段必须构成连续的最左前缀，并在各自表中物理有序。
例如 ON t1.a = t2.x AND t1.b = t2.y，那 t1 表索引必须是 (a, b)，t2 表索引必须是 (x, y)。如果只建了 (a) 和 (y)，或者 t2 上建的是 (y, x)，Merge Join 就无法利用排序，大概率退化。
还要避开这些坑：
- 右表
ON条件中用了函数，比如ON t1.code = UPPER(t2.code)→ 整个索引失效，Merge 流中断 - 联接字段存在隐式转换（
int对varchar、datetime对date）→ 排序流被破坏 - 查询中对联接字段做了计算或表达式（
ON t1.id + 1 = t2.ref_id）→ 无法走有序流
真正难的不是建索引，是让整个查询链路不碰任何破坏排序的操作。哪怕一个 UPPER() 或一次类型转换，都可能让前面所有优化白费。
