merge join性能差主因是数据未物理排序导致插入sort操作符耗cpu；需验证子节点ordered="true"、统计信息新鲜及索引键顺序严格匹配联接条件。
Merge Join 性能差，八成不是它选错了，而是数据根本没排好序。 SQL Server 的 Merge Join 本身不耗 CPU，耗的是前面那个偷偷塞进去的 Sort 操作符。你看到执行计划里带黄色叹号的 Sort 节点，就说明 Merge 正在“假装有序”，实则现场排序——这一步能把 CPU 拉满。
怎么确认 Merge Join 真的免排序？
别只看执行计划写着 Merge Join，得往下钻两层验证：
- 找到
<relop logicalop="Merge Join"></relop>节点，检查它的两个子节点是否都是Index Scan或Clustered Index Seek，且属性Ordered="true" - 对比每个子节点的
EstimatedRows和ActualRows：若偏差超 5 倍（比如预估 200 行、实际 1.2 万行），统计信息大概率过期，Merge 会被迫退化 - 运行
DBCC SHOW_STATISTICS('table_name', 'index_name')，重点看modification_counter；若超过表总行数的 20%，手动更新统计信息：UPDATE STATISTICS table_name WITH FULLSCAN
关联列怎么才算“物理有序”？
有序 ≠ 有索引，而是索引键顺序必须严格匹配联接条件顺序。例如联接写法是 ON a.x = b.y，那必须同时满足：
-
a表上有索引CREATE INDEX ix_a_x ON a(x)（单列即可，顺序一致） -
b表上有索引CREATE INDEX ix_b_y ON b(y)（不能是(y, z)开头但y不是第一键） - 避免在 ON 条件里对字段做任何操作：
UPPER(x)、ISNULL(x, '')、隐式转换（如x = 123但x是varchar）都会破坏有序性
特别注意：聚簇索引主键列天然有序，但若联接用的是非主键列，仍需对应非聚集索引——且该索引不能包含无关列导致页分裂打乱物理顺序。
SSIS 里的 Merge Join 和数据库里不是一回事
SSIS 的 Merge Join 转换完全不查索引，只认两个硬性标记：IsSorted = true 和列级 SortKeyPosition。它不会帮你排序，也不会报错，数据若实际无序，结果直接错乱。
- 最稳做法：在
Merge Join前加一个Sort转换（它会自动设IsSorted和SortKeyPosition） - 想跳过 Sort 转换？必须在源查询里用
ORDER BY，但注意：ORDER BY默认用 SQL Server 排序规则，而 SSIS 要求 Windows 排序规则——字符串列必须先转nvarchar再ORDER BY，否则顺序可能错位 - 手设
IsSorted = true是高危操作：一旦上游数据流实际未排序，下游所有逻辑都不可信，且无任何警告
什么时候不该强求 Merge Join？
强行让小表走 Merge，不如让它走 Nested Loops；两表都无序还硬加索引只为 Merge，IO 和维护成本反而更高。
- 适合 Merge 的场景：两表都大（>100 万行）、联接字段天然有序（如按时间分区的表、自增主键日志表）、后续要
TOP/OFFSET或嵌套在APPLY中需要流式输出 - Hash Join 更合适的情况：一表极小（
- 真正容易被忽略的点：Merge Join 的内存占用恒定，但对磁盘 IO 敏感——如果排序字段的索引页碎片率 >30%，即使
Ordered="true"，物理读也会暴涨
