Merge Join易CPU高是因为缺乏天然排序时会插入Sort操作符；需确保联接字段物理有序、查询不破坏排序前提、统计信息足够新，否则强制Merge仍会引发高CPU。
为什么 Merge Join 在 SQL Server 中容易 CPU 高？
Merge Join 的本质是两个已排序的数据流做归并，它不依赖索引，但极度依赖输入数据的有序性。如果 SQL Server 发现参与联接的字段没有天然排序（比如没走索引、或索引顺序不匹配联接条件），就会在执行前插入一个 Sort 操作符——这正是 CPU 暴增的元凶。你看到执行计划里出现黄色叹号+“Sort”节点，基本就坐实了问题。
如何让 Merge Join 真正“免排序”？
关键不是“让优化器选 Merge Join”，而是“让它能直接用上已排序的数据”。必须同时满足以下三点：
- 联接字段（
ON a.x = b.y）在各自表中物理有序：要么有对应列的索引，且索引键顺序严格匹配联接顺序（例如CREATE INDEX ix_a_x ON a(x)、CREATE INDEX ix_b_y ON b(y)） - 查询中不破坏排序前提：避免在该字段上做函数操作（如
UPPER(x)）、隐式转换（如x = 123但 x 是varchar）、或加TOP/OFFSET导致优化器放弃排序流 - 统计信息足够新：过期的统计信息会让优化器误判数据分布，错误估算排序成本，转而选择 Hash Join 或强制加 Sort
Merge Join vs Hash Join：什么时候该坚持用 Merge？
别盲目追求 Merge Join。它只在特定场景下比 Hash Join 更省 CPU：
- 两表都很大，且联接字段天然有序（如时间分区表按
event_time聚簇、日志表按id自增主键） - 需要稳定流式输出（比如嵌套在 APPLY 中、或后续要 LIMIT/TOP）——Merge Join 支持早期终止，Hash Join 必须建完哈希表才能出第一行
- 内存紧张：Hash Join 会申请大量内存建哈希表，Merge Join 内存占用恒定（仅缓冲几行）
反例：小表 + 大表联接，Hash Join 通常更快；两表都无序，硬加索引只为 Merge，反而增加 IO 和维护开销。
检查与验证：三步确认是否真免排序
别信执行计划里的“Merge Join”字样，要看底层数据流：
- 打开实际执行计划（
SET STATISTICS XML ON），找Index Scan或Clustered Index Seek，且Ordered="true" - 对比
EstimatedRows和ActualRows：若差距巨大（比如预估 100 行、实际 10 万行），说明统计信息不准，Merge 可能被迫退化 - 用
DBCC SHOW_STATISTICS('table', 'index_name')查看modification_counter，超过阈值（约 20% 行数变化）就手动更新统计信息：UPDATE STATISTICS table WITH FULLSCAN
真正有效的 Merge Join 优化，90% 功夫花在索引设计和统计信息维护上，而不是调参数。一旦排序流断裂，再怎么 hint 强制 OPTION (MERGE JOIN)，也只是把 Sort 操作从运行时提前到编译时，CPU 还是照烧不误。
