Merge Join真正免排序需满足：两输入均为有序索引扫描且Ordered="true"，方向一致、无隐式转换、统计信息准确；否则实际执行仍会触发Sort操作消耗CPU。
必须满足排序前提：连接字段上数据已有序
Merge Join 不会自己排序，它只接受已有序的输入流。数据库执行计划中，Merge Join 节点的左右子节点必须都带 Ordered="true" 属性——这通常意味着它们是 Index Scan 或 Index Only Scan，且索引顺序与 ON 条件完全匹配。
常见破坏有序性的操作：
-
ON a.id = UPPER(b.user_id)：函数导致b.user_id索引失效，触发隐式Sort -
ON a.status = b.status，但索引是INDEX (created_at, status)：最左前缀不匹配，无法提供status有序流 - 字段类型不一致，如
a.user_id INT与b.user_id BIGINT：隐式转换使索引无法用于排序输出
连接条件必须是等值比较（=）
Merge Join 只支持 ON 子句中纯等值判断，比如 a.x = b.y。一旦出现 、<code>>=、IN、BETWEEN 或多个条件用 AND 组合（如 a.x = b.y AND a.flag = 1），优化器基本不会选它——因为归并逻辑只靠“相等就输出，小的就推进”驱动。
注意：WHERE 中的非等值过滤不影响 Merge Join 的选择，但会大幅增加 Rows Removed by Filter，削弱其性能优势。
统计信息要准确，且优化器得“信得过”唯一性
即使两个表在连接字段上实际无重复值，优化器也不会默认按 one-to-many 处理，除非它有明确依据：
- 某张表在连接列上有
UNIQUE CLUSTERED INDEX（SQL Server）或PRIMARY KEY（PostgreSQL/MySQL） - 查询中显式包含
DISTINCT、GROUP BY或ROW_NUMBER() OVER (PARTITION BY ...)等能推导唯一性的操作符 - 统计信息过期会导致优化器误判基数，可能跳过 Merge Join 或选错驱动顺序
没这些信号，即使建了普通索引，优化器也倾向走 many-to-many 模式，内部用临时空间缓存重复键的匹配行，反而增加 I/O 开销。
为什么加了索引还不走 Merge Join？
加索引只是必要条件，不是充分条件。真正卡住的往往是执行路径的“链路完整性”：
- 两张表都得有对应字段的索引：若
ON u.id = o.user_id，则users(id)和orders(user_id)都需索引 - 索引必须能覆盖排序需求：例如
orders表按user_id建的是NONCLUSTERED，而查询还带ORDER BY o.created_at，优化器可能放弃索引扫描改走Sort + Nested Loop - 执行计划里看到
Merge Join但子节点含Sort：说明正在后台偷偷排序，此时不是真正的 Merge Join 加速，而是“假合并、真排序”
最易被忽略的一点：Merge Join 的优势只在线性归并阶段体现，一旦因数据倾斜、高滤除率或统计偏差导致大量无效比较，它的恒定内存优势就转为 CPU 热点。确认是否真生效，必须看 EXPLAIN (ANALYZE, BUFFERS) 中子节点是否真的 Ordered 且无 Sort 节点。
