merge join在有序数据上不耗cpu，根本原因是跳过最耗资源的sort阶段，仅执行轻量级双指针归并；需验证子节点为index scan/clustered index seek且ordered="true"，否则隐式排序将拉高cpu。
为什么Merge Join在有序数据上不耗CPU
Merge Join快，不是因为它算法多精妙，而是它压根不干排序这活儿。真正吃CPU的是Sort操作符——一旦两个输入流天然有序（比如走Clustered Index Seek或Index Scan且Ordered="true"），SQL Server或PostgreSQL就跳过排序，直接双指针归并：每次只比对当前两行键值，相等就输出，小的一方指针右移。整个过程内存恒定、无哈希建表、无磁盘spill。
怎么确认Merge Join真没排序
别信执行计划顶上写着Merge Join就完事。必须下钻看它的两个直接子节点：
- 必须都是
Index Scan或Clustered Index Seek（不能是Sort或Seq Scan） - 每个子节点XML属性里得有
Ordered="true" - 用
DBCC SHOW_STATISTICS('table', 'index_name')查modification_counter，超总行数20%就得UPDATE STATISTICS table WITH FULLSCAN -
EstimatedRows和ActualRows偏差超5倍，说明统计不准，Merge可能已被迫降级
哪些写法会让Merge Join悄悄变慢
哪怕索引建得再准，以下操作也会让优化器放弃有序流，硬插一个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、OFFSET或FOR XML，优化器可能认为“排序流不可靠”，转而选Hash Join
什么时候坚持用Merge Join反而更糟
Merge Join不是万能加速器，它只在特定条件下赢：
- 两表都很大（千万级以上），且联接字段天然有序（如日志表按
event_time聚簇、订单表主键自增） - 需要流式输出或早期终止（比如外层带
LIMIT 100，Merge能扫几万行就停，Hash必须建完全部哈希表才吐第一行） - 内存紧张时——Hash Join会申请大量内存，Merge只缓存几行
- 反例：小表+大表关联，
Nested Loops或Hash Join通常更快；两表都无序却硬加索引只为凑Merge，IO和维护成本反而更高
Merge Join就会从加速变成背锅侠。
