Postgres使用游标执行Join查询的机制与普通查询对比

Postgres处理游标结合FETCH的Join查询时，核心逻辑是尽可能延迟全量计算，根据FETCH的批量需求逐步生成并返回结果，和普通查询的全量（或LIMIT截断）处理有明显区别，具体取决于Join的执行计划类型：

1. 普通Join查询的逻辑 #

普通的Join查询（不带游标），Postgres会执行完整的Join计划：

• 如果没有LIMIT，会计算出所有匹配的结果行，一次性返回给客户端；
• 如果带LIMIT，优化器会尝试提前终止计算（比如嵌套循环下找到足够行数就停止），但本质是为了快速拿到满足LIMIT的结果，而非为了分批获取设计。

2. 游标+FETCH的Join执行逻辑 #

游标是为分批获取结果设计的，Postgres会针对游标场景优化执行计划，不同Join类型的行为不同：

嵌套循环Join（Nested Loop） #

这是最适配游标的Join类型：

• Postgres会先遍历外表的少量行（比如根据FETCH的行数预估），然后针对每一行去内表查找匹配的行；
• 一旦凑够FETCH指定的行数，就立即返回结果，剩余的外表遍历和内表匹配操作会暂停，等下次FETCH NEXT时再继续；
• 完全不需要等待整个Join操作完成，真正实现了"部分Join逐步返回"。

哈希Join（Hash Join） #

这种Join需要先为其中一张表（通常是小表）构建完整的哈希表，这一步无法避免：

• 第一次执行FETCH时，Postgres会先完成哈希表的构建，然后开始遍历另一张表的行进行匹配；
• 匹配过程中凑够指定行数就返回，后续FETCH会继续从剩余的匹配过程中取数，不需要重复构建哈希表；
• 虽然需要先完成哈希表构建，但后续是逐步返回结果，而非等全量匹配完成。

合并Join（Merge Join） #

合并Join要求两张表的Join字段是有序的（无索引则先排序）：

• 第一次FETCH时，Postgres会先完成排序操作（如果需要），然后开始逐行匹配两张有序表的行；
• 凑够指定行数后返回，后续FETCH继续从排序后的结果中匹配取数；
• 同样，排序是前置必须完成的步骤，但匹配和返回是逐步进行的。

3. 关键差异总结 #

举个简单的游标使用示例：

-- 声明游标，关联两张表的Join查询
DECLARE order_cursor CURSOR FOR 
  SELECT o.order_id, c.customer_name 
  FROM orders o 
  JOIN customers c ON o.customer_id = c.customer_id;

-- 第一次获取10行结果
FETCH 10 FROM order_cursor;

-- 后续获取下一批10行
FETCH NEXT 10 FROM order_cursor;

内容的提问来源于stack exchange，提问作者Arjunlal M.A