Merge JOIN表现最优的前提是两输入流已按连接键物理有序，此时跳过Sort阶段直接双指针归并；若任一子节点非Index Scan或Ordered="false"，则强制插入Sort节点，显著拖慢性能。
Merge JOIN的归并逻辑依赖物理有序性
Merge JOIN不是“边查边排”，而是直接双指针归并——它假设两个输入流已经按连接键升序（或同为降序）排列。一旦发现某侧数据乱序，就无法做一次遍历比对，必须先插入Sort节点补救。这个Sort不显眼但吃CPU，尤其在大结果集下可能占执行耗时70%以上。
PostgreSQL里“有序”只认Index Scan + Ordered="true"
索引存在 ≠ 数据流有序。PostgreSQL判断是否能跳过排序，只看执行计划中子节点是否为Index Scan且属性Ordered="true"。常见破坏点包括：
-
WHERE customer_id::text = '123'—— 类型转换让索引失效，退化为Seq Scan -
ORDER BY customer_id DESC NULLS LAST—— 与B-tree索引默认升序不匹配，Ordered变为false - 统计信息陈旧（
modification_counter> 表总行数20%），导致优化器误判索引扫描成本过高而弃用
强制走Merge JOIN却变慢？大概率隐式Sort已生效
用SET enable_hashjoin = off; SET enable_nestloop = off强行推Merge JOIN，不代表真免排序。务必检查实际执行计划（EXPLAIN ANALYZE）：
- 找到
Merge Join节点，往下钻两层，确认两个子节点都是Index Scan，且XML里含Ordered="true" - 如果看到
Sort节点挂在Merge Join下面，说明正在现场排序——此时Hash Join反而更快 - 连接字段类型不一致（如
intvsbigint）也会触发隐式转换，让索引顺序不可复用
真正免排序的最小可行条件
要让Merge JOIN不带Sort跑起来，三件事缺一不可：
- 两侧连接列都有B-tree索引，且最左列为连接字段（如
CREATE INDEX ON orders (customer_id)） - 查询条件不破坏索引使用：不用函数、不隐式转类型、不加
LIMIT/OFFSET - 执行计划里两个
Index Scan节点都标着Ordered="true"，且Actual Rows与Estimated Rows偏差不大（
少一个条件，Merge JOIN就只是名字叫得响，实际还是在后台默默排序。
