PostgreSQL 16 默认不强制走 Merge Join，需满足双侧连接列严格有序、均有可用 B-tree 索引、查询走 Index Scan 且无破坏有序性的条件（如函数操作、非单调排序），否则优化器会选 Hash Join 或 Nested Loop。
PostgreSQL 16 默认不会强制走 Merge Join，但你可以通过索引 + 排序约束 + hint 或配置组合实现稳定触发——前提是数据或访问路径天然满足有序性，否则强行“压”只会让查询更慢甚至报错。
为什么 Merge Join 没被选中？先看执行计划里缺什么
Merge Join 不是“设个开关就能开”的连接方式，它依赖两个输入流都按连接键严格有序。如果你的 EXPLAIN ANALYZE 里没出现 Merge Join 节点，常见原因有：
- 连接列上没有可用索引，或者索引未被选用（比如用了
WHERE col LIKE 'a%'导致索引失效） - 表本身无排序，且优化器估算走 Index Scan + 排序成本 > Hash Join，就直接跳过了
- 连接字段类型不一致（如
intvsbigint），导致无法复用索引顺序 - 查询含
LIMIT、OFFSET或非单调排序（如ORDER BY x DESC NULLS LAST），破坏了 merge 的流式前提
确保驱动侧走 Index Scan 是硬前提
Merge Join 要求至少一侧能通过索引按连接键升序/降序扫描，否则优化器连尝试都不会尝试。验证方式：
- 对连接列建 B-tree 索引：
CREATE INDEX ON orders (customer_id)和CREATE INDEX ON customers (customer_id) - 确认查询条件允许索引下推：避免在连接列上做函数操作，如
ON o.customer_id::text = c.customer_id::text - 检查
EXPLAIN中对应表是否出现Index Scan using xxx on table_name，而不是Seq Scan或Bitmap Heap Scan
如果某侧仍是全表扫描，Merge Join 就不可能发生——因为另一侧再有序也没法“合并”。
用 pg_hint_plan 显式指定 MergeJoin 并验证生效
装好 pg_hint_plan 后，可直接在 SQL 中加提示。注意语法必须严格：
- 提示块必须以
/*+开头、*/结尾，中间不能换行（除非用空格续行） - 表名要用查询中定义的别名，不是物理表名：
/*+ MergeJoin(o c) */，不是MergeJoin(orders customers) - 必须配合索引存在，否则提示会被忽略，执行计划仍显示
Hash Join或Nested Loop
示例：
/*+ MergeJoin(o c) IndexScan(o orders_customer_id_idx) IndexScan(c customers_pkey) */ SELECT o.order_id, c.customer_name FROM orders o JOIN customers c ON o.customer_id = c.customer_id;
运行后立刻查 EXPLAIN ANALYZE，确认顶层节点是 Merge Join，且子节点是 Index Scan —— 如果看到 Sort 节点包在 Merge Join 外面，说明索引没覆盖排序方向，或统计信息过期，需 ANALYZE customers, orders。
work_mem 和 enable_sort 配合调优易被忽略
Merge Join 自身不消耗太多内存，但它依赖的索引扫描若要支持反向排序（ORDER BY ... DESC），可能触发额外排序。这时容易踩坑：
-
work_mem过小会导致Sort落盘，拖慢整体速度；但 Merge Join 本身不需要调大work_mem - 如果已确认两侧都有正向索引，却仍看到
Sort节点，可临时禁用排序强制走 merge：SET LOCAL enable_sort = off，再跑EXPLAIN看是否转成纯Merge Join - 注意：禁用
enable_sort是诊断手段，不可长期开启，否则其他查询会崩
真正稳定的 Merge Join 往往出现在分区表场景（如按时间分区的订单表 join 客户表），此时每个子分区自带 created_at 索引，Merge Append + Merge Join 才能链路打通——而这点在单表 JOIN 中常被低估。
