递归CTE为何仅处理上一轮迭代新增记录？技术原理问询

你提到的这个行为，是SQL标准对递归CTE（WITH RECURSIVE）的明确规定，不是数据库引擎的“特殊处理”，也不需要盲目信任——核心是递归CTE的执行是迭代式的，而非一次性扫描全量结果。

拆解你的示例执行流程 #

以你给出的日期生成CTE为例，数据库的执行步骤是这样的：

• 锚点成员执行：先运行SELECT '2023-01-01'::timestamp AS date，得到初始结果集（称为“种子集”）：['2023-01-01']。
• 第一次递归迭代：执行递归成员SELECT date + interval '1 day' FROM date_range WHERE date < '2023-12-31'——这里的date_range仅引用上一轮迭代产生的行（也就是种子集里的2023-01-01），生成2023-01-02，将其加入总结果集，此时总结果是['2023-01-01', '2023-01-02']。
• 第二次递归迭代：再次执行递归成员，此时date_range引用的是上一轮新增的行（也就是2023-01-02），生成2023-01-03，加入总结果。
• 重复迭代：每一轮递归都只使用上一轮刚生成的行作为输入，直到递归成员返回空结果（当生成的日期等于2023-12-31时，WHERE date < '2023-12-31'不满足，递归停止）。

为什么不扫描全量结果？ #

如果递归成员每次都扫描所有已生成的行，你的示例会出现严重逻辑错误：比如到第三轮时，会同时用2023-01-01、2023-01-02、2023-01-03生成2023-01-02、2023-01-03、2023-01-04，导致大量重复数据，甚至陷入无限循环（只要还有行满足WHERE条件，就会不断重复生成）。

SQL标准规定递归CTE的递归成员仅处理“上一轮增量”，正是为了保证递归逻辑的可控性，让开发者能通过简单的条件实现有序的迭代生成（比如日期序列、层级结构）。

所有支持递归CTE的主流数据库（PostgreSQL、MySQL、SQL Server等）都遵循这个执行规则，这是可预期的行为，不是需要“默认信任”的黑盒。

内容的提问来源于stack exchange，提问作者WestCoastProjects