merge join真正免排序需满足：两输入均为有序索引扫描且ordered="true"，方向一致、无隐式转换、统计信息准确；否则实际执行仍会触发sort操作消耗cpu。
确认执行计划里Merge Join是否真免排序
看到执行计划写着Merge Join不等于它真的省CPU——八成问题出在它前面偷偷塞了个Sort操作符。必须打开实际执行计划（SET STATISTICS XML ON），找到<relop logicalop="Merge Join"></relop>节点，往下钻两层：两个子节点是否都是Index Scan或Clustered Index Seek，且属性Ordered="true"。
如果任一子节点是Table Scan、Non-Clustered Index Scan（但索引键顺序不匹配）或Compute Scalar，那Merge Join就是在“假装有序”，现场排序把CPU拉满。
- 检查
EstimatedRows和ActualRows偏差：超5倍说明统计信息过期，DBCC SHOW_STATISTICS('table_name', 'index_name')看modification_counter，超过总行数20%就立刻UPDATE STATISTICS table_name WITH FULLSCAN - 聚簇索引主键列天然有序，但若ON条件用的是非主键列，必须有对应单列索引（如
CREATE INDEX ix_b_y ON b(y)），不能是(y, z)这种复合索引——y必须是第一键 - 避免在ON里写
UPPER(x)、ISNULL(x, '')、x = 123（x是varchar）——隐式转换直接废掉排序性
验证JOIN字段是否物理有序而非仅“有索引”
有索引 ≠ 物理有序。SQL Server的Merge Join只认B-tree索引的物理存储顺序，不是逻辑顺序。比如orders表按order_date DESC建了聚簇索引，但JOIN写的是ON o.order_date = c.created_date，而c.created_date索引是ASC，方向不一致也会触发Sort。
- 两边索引必须同向：要么都是
ASC，要么都是DESC；混合方向不被Merge Join识别为有序输入 - 字符串列特别敏感：SQL Server排序规则（SQL_Latin1_General_CP1_CI_AS）和Windows排序规则（Latin1_General_100_CI_AS）顺序可能不同，SSIS里更明显；若用ORDER BY强制排序，
varchar列要先CONVERT(nvarchar, x)再ORDER BY - 索引包含无关列（如
CREATE INDEX ix_a_x ON a(x, status)）会导致页分裂，物理顺序被打乱，即使key列相同，Merge Join也可能退化
OPTION (MERGE JOIN)提示为什么静默失效
OPTION (MERGE JOIN)不是强制指令，而是优化器采纳的前提型建议。只要以下任一条件不满足，它就直接忽略提示，改用Hash Join或Nested Loops，执行计划里连Merge Join算子都不会出现。
- 连接必须是等值（
=），不支持、>等非等值条件 - 两边连接列数据类型必须完全兼容：
int对bigint、varchar(50)对varchar(100)都可能触发隐式转换，破坏排序保证 - 驱动表不能带
TOP、OFFSET或FOR XML等会干扰排序流的语法——优化器无法保证后续行仍有序 - 如果缺索引，加提示会直接报错
Query processor could not produce a query plan，而不是降级执行
什么时候该放弃Merge Join强行优化
硬凑Merge Join反而拖慢查询。真正适合它的场景很窄：两表都大、连接键天然有序、基数高（重复值少）、内存紧张。
- 小表+大表关联：用
Nested Loops更快，Merge Join要双排序，IO开销更大 - 连接键只有3–5个不同值（如状态码表）：
Hash Join建一次哈希表就能复用，Merge Join要反复嵌套匹配，性能骤降 - 数据源本身无序且无法加索引（如临时表、表变量）：与其硬加
OPTION (MERGE JOIN)失败，不如直接用OPTION (HASH JOIN)并调大max server memory - SSIS里的
Merge Join转换：它完全不查数据库索引，只认IsSorted = true和SortKeyPosition，上游没真实排序就设这个，结果直接错乱
最稳的做法永远是：先让数据物理有序，再让优化器自己选——而不是反过来用提示去倒逼算法。
