根本原因是Sort Merge Join跳过最耗资源的排序阶段；Merge本身仅指针移动和比对，轻量高效，而Sort才消耗CPU、内存及磁盘I/O。

Sort Merge Join在数据已排序时表现最优，根本原因不是它“快”，而是它彻底跳过了最耗资源的环节——排序本身。

为什么已排序的数据能让Sort Merge Join几乎零开销

数据库执行Sort Merge Join时，实际分两步：先排序（Sort），再归并（Merge）。Merge阶段本身极轻量，只做指针移动和等值比对；真正吃CPU、占内存、触发磁盘I/O的是Sort阶段。一旦两个输入流天然有序（比如走Clustered Index Seek或Index Scan且Ordered="true"），优化器就能直接跳过Sort节点——执行计划里不会出现黄色叹号的Sort操作符，也就没有Sort Method: external merge或Using filesort这类信号。

• 必须验证子节点是否带Ordered="true"属性，仅看上层写着Merge Join不作数
• 若子节点是Table Scan或Index Scan但Ordered="false"，说明数据物理无序，哪怕SQL写了ORDER BY也白搭
• 聚簇索引主键列默认有序，但联接用的是非主键列（如status），仍需对应单列索引CREATE INDEX ix_t_status ON t(status)

哪些操作会悄悄破坏“已排序”前提

即使表上有完美匹配的索引，以下写法也会让优化器放弃利用有序性，强制插入Sort：

• 在ON条件中对字段做任何计算：ON UPPER(a.name) = UPPER(b.name)、ON ISNULL(a.id, 0) = b.id
• 隐式类型转换：ON a.user_id = b.code（a.user_id是INT，b.code是VARCHAR）
• WHERE条件未命中索引最左前缀：INDEX(status, created_at)存在，但查询是WHERE created_at > '2025-01-01'
• 加TOP/LIMIT或OFFSET，可能让优化器认为“排序流不可靠”，转而选择其他连接方式

怎么确认你真的免了排序

不能只看执行计划标题，得下钻验证数据流真实状态：

• 打开实际执行计划（SET STATISTICS XML ON），定位<RelOp LogicalOp="Merge Join">节点，检查其两个子节点的PhysicalOp是否为Clustered Index Seek或Index Scan，且Ordered="true"
• 对比每个子节点的EstimatedRows和ActualRows，若偏差超5倍（如预估200行、实际1.2万行），说明统计信息过期，UPDATE STATISTICS table_name WITH FULLSCAN后再试
• 运行DBCC SHOW_STATISTICS('table', 'index_name')，查modification_counter，若超过总行数20%，就是统计不准的铁证

最容易被忽略的是：排序有序性必须严格对应ON条件字段顺序，且不能有任何中间转换。索引建了、统计更新了、执行计划看着像，三者缺一，Sort就还在后台偷偷干活。