根本原因是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"></relop>节点，检查其两个子节点的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就还在后台偷偷干活。
