merge join仅在双表物理有序、方向一致且无隐式转换时真正免排序；否则执行计划中虽显示merge join，实则隐含sort操作，cpu飙升。
Merge Join不是加个索引就自动快的，它只认物理有序性，不认“看起来有索引”。 真正免排序的Merge Join必须满足三个硬条件：两边输入流在连接列上物理有序、方向一致、无隐式转换。否则执行计划里那个Merge Join节点只是个幌子，底下悄悄藏着Sort操作符，CPU直接拉满。
确认执行计划中Merge Join是否真免排序
别信执行计划图里写了Merge Join就以为省事了。必须打开实际执行计划（SET STATISTICS XML ON），找到<relop logicalop="Merge Join"></relop>节点，往下看它的两个直接子节点：
- 必须都是
Index Scan或Clustered Index Seek，不能是Table Scan、Non-Clustered Index Scan（除非该非聚集索引键顺序严格匹配ON字段）或Compute Scalar - 两个子节点的
Ordered="true"属性必须同时存在且为true - 检查
EstimatedRows和ActualRows偏差：超过5倍说明统计信息过期，DBCC SHOW_STATISTICS('table_name', 'index_name')查modification_counter，超总行数20%就立刻UPDATE STATISTICS table_name WITH FULLSCAN
确保JOIN字段物理有序且方向一致
有索引 ≠ 物理有序。SQL Server的Merge Join只按B-tree页的物理存储顺序走，不是按你ORDER BY逻辑顺序。
- 聚簇索引主键列天然有序，但若
ON用的是非主键列（如ON o.order_date = c.created_date），那o表必须有CREATE INDEX ix_o_order_date ON o(order_date)——order_date必须是单列索引的第一键，不能是(order_date, status)这种复合索引 - 两边索引方向必须一致：
ASC对ASC，或DESC对DESC；混合方向（如一端ASC、另一端DESC）会被视为无序，触发Sort - 字符串列尤其敏感：
varchar列在不同排序规则（如SQL_Latin1_General_CP1_CI_ASvsLatin1_General_100_CI_AS）下物理顺序可能不一致，SSIS场景更常见
避免破坏排序性的写法和类型问题
任何在ON条件里对连接列做计算或转换的操作，都会让优化器放弃使用已排序流。
- 禁用函数包装：
UPPER(x)、ISNULL(x, '')、CONVERT(int, x)全都不行 - 禁用隐式转换：
ON a.id = b.id_str（a.id是int，b.id_str是varchar）会强制b表走转换+Sort；必须显式统一类型，且保证索引能走 -
TOP、OFFSET、FOR XML等操作可能让优化器退化为Hash Join或插入Sort，即使原查询本身有序 - 索引包含无关列（如
CREATE INDEX ix_a_x ON a(x, status)）会导致页分裂，物理顺序被打乱，Merge Join可能降级
为什么OPTION (MERGE JOIN)提示经常静默失效
OPTION (MERGE JOIN)不是强制指令，而是优化器采纳的前提型建议。只要以下任一条件不满足，它就直接忽略，改用Hash Join或Nested Loops，执行计划里连Merge Join算子都不会出现。
- 连接条件不是纯等值：
ON a.x = b.y可以，ON a.x > b.y或ON a.x b.y不行 - 两边连接列数据类型不完全兼容：
int对bigint、varchar(50)对varchar(100)都可能触发隐式转换，破坏排序保证 - 任意一侧缺少匹配方向的索引，或索引键顺序不覆盖
ON字段（比如ON a.x = b.y，但b表只有(z, y)索引）
最常被忽略的一点是：Merge Join只在两表都大（千万级以上）、且天然有序时才有优势；小表+大表关联，Hash Join通常更快；强行凑Merge Join反而增加IO和索引维护成本。
