DuckDB窗口函数在UUID分区下使用UNBOUNDED FOLLOWING时返回空值问题分析

问题现象

在使用DuckDB数据库时，当窗口函数配置为ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING范围时，偶尔会出现返回NULL值而非预期聚合结果的情况。这个问题在DuckDB 1.2.1版本中出现，而在1.2.0版本中表现正常。

问题复现条件

经过分析，该问题在以下特定条件下会出现：

1. 窗口函数基于主表进行分区，同时对连接表进行聚合操作
2. 连接条件和分区字段使用UUID类型（使用字符串类型则表现正常）
3. 窗口范围设置为包含UNBOUNDED FOLLOWING
4. 仅在多线程环境下出现（设置pragma threads=1可避免）

技术分析

这个问题源于DuckDB的"constant"聚合器实现缺陷。当使用UUID作为分区键并结合UNBOUNDED FOLLOWING窗口范围时，在多线程环境下会导致聚合结果偶尔返回NULL。

从技术实现角度看，窗口函数处理流程中：

1. 数据首先按照分区键（UUID）进行分组
2. 每个分组内的数据根据ORDER BY子句排序
3. 对每个行计算定义的窗口范围
4. 在UNBOUNDED FOLLOWING情况下，需要聚合分区内所有后续行

问题出现在多线程处理这些步骤时，线程间的同步机制未能正确处理UUID类型的比较和聚合操作，导致部分聚合结果丢失。

解决方案

目前有以下几种解决方案：

1. 临时解决方案：

   • 设置单线程模式：PRAGMA threads=1
   • 将UUID转换为字符串类型作为分区键

2. 长期解决方案：

   • 升级到修复该问题的DuckDB版本（该问题已在后续提交中修复）
   • 避免在关键业务中使用UUID分区键结合UNBOUNDED FOLLOWING窗口

影响范围

该问题不仅影响array_agg函数，同样会影响其他聚合函数如sum等。开发者在涉及以下场景时应特别注意：

• 使用窗口函数进行跨行计算
• 分区键使用UUID类型
• 需要计算整个分区范围的聚合结果

最佳实践建议

1. 在升级数据库版本时，应对窗口函数逻辑进行全面测试
2. 对于关键业务逻辑，考虑使用更稳定的窗口范围定义
3. 在必须使用UUID作为分区键时，可先转换为字符串类型
4. 在开发环境中模拟多线程压力测试，确保聚合结果一致性

通过理解这个问题的本质，开发者可以更好地规避类似问题，并设计出更健壮的数据库查询逻辑。