DuckDB递归CTE查询结果不一致问题分析

问题背景

在DuckDB数据库项目中，测试套件中发现了一个关于递归公用表表达式(Recursive CTE)的问题。具体表现为在recursive_cte_key_variant.test测试文件中，当执行带有USING KEY子句的递归CTE查询时，原始查询结果与复制后的查询结果出现了不一致。

问题现象

测试用例执行了一个包含三个表连接的递归CTE查询：

WITH RECURSIVE tbl(a,b,c) USING KEY (a) AS 
(SELECT 1, NULL, NULL 
 UNION 
 SELECT tbl.a+1, rec1.a, rec2.b 
 FROM tbl, recurring.tbl AS rec1, recurring.tbl AS rec2 
 WHERE tbl.a < 5) 
SELECT * FROM tbl;

预期结果应该是：

1	NULL	NULL
2	1	NULL
3	2	1
4	3	2
5	4	3

但实际复制后的查询却产生了不同的结果：

1	NULL	NULL
2	1	NULL
3	2	1
4	2	2
5	4	2

特别是在第4行和第5行，列值出现了明显差异。

技术分析

递归CTE的工作原理

递归CTE是SQL中一种强大的特性，它允许查询引用自身。通常由两部分组成：

1. 基础部分：提供初始结果集
2. 递归部分：引用CTE本身，通过UNION ALL连接

USING KEY子句的作用

USING KEY子句在DuckDB中用于指定递归CTE的键列，这会影响递归查询的执行计划和结果生成方式。在这个案例中，指定了列a作为键。

问题根源

从错误信息"Copied statement differs from original result"可以推断，问题可能出现在查询优化器或执行引擎处理递归CTE时的某些环节：

1. 可能是在查询计划复制过程中丢失了某些关键信息
2. 或者是递归部分的连接条件处理不正确
3. 也可能是USING KEY子句的实现存在缺陷

解决方案

开发团队通过两个提交修复了这个问题：

1. 首先修正了递归CTE中键处理的逻辑
2. 然后完善了查询结果验证机制

修复后，递归CTE现在能够正确维护键约束，并在复制查询时保持结果一致性。

经验总结

这个案例展示了数据库系统中几个重要方面：

1. 递归查询的实现复杂性
2. 查询优化器在保持语义一致性方面的挑战
3. 全面测试覆盖的重要性

对于数据库开发者而言，这类问题提醒我们需要特别注意：

• 递归CTE中键约束的正确处理
• 查询计划复制时的语义保持
• 复杂查询结果的验证机制

对于DuckDB用户来说，这个修复确保了递归查询结果的可靠性，特别是在使用USING KEY等高级特性时。