merge join本身不排序，高cpu主因是优化器强制插入sort节点：当输入数据未按连接键有序时，即使有索引，若类型不一致、where破坏有序性或统计信息过期，仍会触发隐式排序。
为什么Merge Join执行计划里总带Sort节点
Merge Join本身不排序，它只做归并。但SQL Server发现两个输入流的连接字段（比如ON a.id = b.a_id）没有天然有序时，就会在执行前硬插一个Sort操作符——这才是CPU飙高的直接原因。你看到执行计划里Merge Join上方有个黄色叹号+Sort，基本就定位到根子上了。
在连接字段建索引≠自动跳过Sort
建索引只是必要条件，不是充分条件。必须同时满足：
-
a.id上要有单列索引（如CREATE INDEX ix_a_id ON a(id)），且该索引是CLUSTERED或至少能保证扫描时物理有序 -
b.a_id上也要有对应单列索引（如CREATE INDEX ix_b_a_id ON b(a_id)），不能靠联合索引的第二列“捎带” - 查询中不能对这些字段做任何破坏有序性的操作：比如
WHERE UPPER(a.id) = '123'、a.id + 0 = b.a_id、或WHERE a.id IN (SELECT ...)这类子查询 - 字段类型必须严格一致：
INTvsBIGINT、VARCHAR(50)vsVARCHAR(100)都可能触发隐式转换，导致索引失效
怎么验证索引真被用来免排序
别信“用了Merge Join”这个表象，得看底层数据流是否真的有序：
- 打开实际执行计划（
SET STATISTICS XML ON），找到<relop logicalop="Merge Join"></relop>节点，往下看它的两个子节点是否都是Index Scan或Clustered Index Seek，且属性Ordered="true" - 检查
EstimatedRows和ActualRows是否接近；如果差10倍以上，说明统计信息过期，优化器误判了排序成本，用UPDATE STATISTICS table_name WITH FULLSCAN强制更新 - 运行
DBCC SHOW_STATISTICS('b', 'ix_b_a_id')，看modification_counter是否超过表行数的20%，超了就得更新
SSIS里的Merge Join为什么也报错“未排序”
SSIS的Merge Join转换和数据库引擎逻辑不同：它不自己排序，只校验排序元数据。即使你在SQL里加了ORDER BY，SSIS也不会认——因为ORDER BY用的是SQL Server排序规则，而SSIS要求Windows排序规则。
- 安全做法：在数据流里插一个
Sort转换，它会自动设好IsSorted=True和SortKeyPosition属性 - 如果坚持用SQL源排序，必须先把
VARCHAR转成NVARCHAR再ORDER BY，否则排序顺序可能错位，导致合并结果乱序甚至丢数据 - 手动设置
IsSorted为True只是“告诉SSIS我排好了”，不校验也不排序；数据实际无序，结果不可预知
TOP、OFFSET、GROUP BY或窗口函数，SQL Server就可能放弃利用已排序流——它认为“排序价值被后续操作抵消了”。这时候Merge Join还是会被降级或加Sort。
