Merge JOIN必须输入已排序数据流，其本身不排序；所谓“先排序”实为优化器补的Sort操作，触发原因包括连接列无匹配方向索引或查询破坏有序前提。

Merge JOIN为什么必须先排序？它根本不做排序

Merge JOIN本身不排序，也不“必须先排序”——它只接受已排序的输入流。你看到的“排序”，是数据库在执行计划里悄悄补上的Sort操作符，因为你的数据流根本没按连接键物理有序。

真正触发Sort的原因只有两个：

• 任一表的连接列没有匹配方向的索引（比如ON a.ts = b.event_time，但b表只有INDEX (event_time DESC)，而a表是ASC）
• 查询破坏了有序前提：如ON UPPER(a.code) = b.code、WHERE b.status IN ('A','B')配合INDEX (status, created_at)（未命中左前缀）

只要子节点不是Index Scan或Clustered Index Seek且带Ordered="true"，那Merge JOIN就在假装高效——实际CPU高、延迟大，全是Sort干的。

怎么确认排序真被跳过了？别信执行计划标题

打开实际执行计划（SET STATISTICS XML ON），定位到<relop logicalop="Merge Join"></relop>节点，往下看它的两个直接子节点：

• 必须都是Index Scan或Clustered Index Seek（不能是Sort、Table Scan或Compute Scalar）
• 每个子节点XML属性中必须含Ordered="true"
• 对比EstimatedRows和ActualRows：偏差超5倍，说明统计信息过期，优化器可能已降级
• 运行DBCC SHOW_STATISTICS('table', 'index_name')，查modification_counter；若超过总行数20%，立刻UPDATE STATISTICS table WITH FULLSCAN

如果其中任意一条不满足，Merge JOIN就不是免排序，而是“现场排序+归并”的组合拳。

Merge JOIN比Hash JOIN快的硬条件，缺一不可

Merge JOIN不是通用加速器，它只在以下三点同时成立时才有优势：

• 两表都足够大（例如各千万行以上），且连接键天然物理有序（如日志表按event_time聚簇、订单表主键自增）
• 查询需要流式输出或早期终止（如外层有LIMIT 100、嵌套在CROSS APPLY中）——Merge能边扫边出，Hash必须建完哈希表才吐第一行
• 内存紧张：Hash JOIN会申请大量内存建表，Merge只缓存几行用于双指针归并，内存恒定（通常<10 KB）

反例很常见：小表+大表关联，Hash JOIN通常更快；两表都无序却硬加索引只为凑Merge，IO和维护成本反而更高。

最容易被忽略的细节：有序性必须严格对齐

你建了索引、写了ORDER BY、执行计划看着像——这三者全对，Merge JOIN仍可能失效。

原因在于：

• 索引方向必须一致：ASC对ASC，DESC对DESC；混合方向不被识别为有序输入
• 字段类型必须完全兼容：INT对BIGINT、VARCHAR(50)对VARCHAR(100)都可能触发隐式转换，废掉排序性
• 字符串列受排序规则影响：SQL_Latin1_General_CP1_CI_AS和Latin1_General_100_CI_AS顺序不同，跨库JOIN时尤其容易崩

真正的难点从来不是“有没有索引”，而是查询条件、字段类型、索引定义、统计信息四者严丝合缝地对齐。漏掉任意一环，Merge JOIN就从加速器变成背锅侠。