QuestDB中SAMPLE BY与时间戳计算组合查询的列丢失问题分析

问题现象

在使用QuestDB 8.1.1版本时，发现一个特殊的SQL查询场景会导致结果集列丢失。当查询同时包含以下两个要素时：

1. 对时间戳列进行内联计算（如timestamp+60000000）
2. 使用SAMPLE BY时间分组

查询结果会丢失SELECT子句中的最后一列。例如以下查询：

SELECT timestamp+60000000 as 'timestamp', 0 AS "extra_column"
FROM sample_table
SAMPLE BY (1m);

结果只会返回timestamp列，而extra_column会丢失。

问题复现条件

通过系统测试发现，该问题具有以下特征：

1. 必须同时存在时间计算和SAMPLE BY：单独使用其中任一功能时表现正常
2. 列丢失具有规律性：总是丢失SELECT子句的最后一列
3. 列数影响表现：当SELECT包含3列时，会保留前两列而丢失第三列
4. 时间计算是触发条件：直接使用原始时间戳列不会触发该问题

技术原理分析

QuestDB的SQL优化器在处理这类查询时，会执行rewriteSampleBy重写操作。该操作的核心逻辑是：

1. 时间列重写：当检测到时间戳列的别名引用时（如timestamp as ts），优化器会将这些引用从当前查询模型中移除，然后在包装查询模型中重新添加
2. 依赖关系断裂：问题在于当移动的时间戳列依赖于子查询模型的输出列时，会导致依赖关系断裂
3. 列名冲突：重写过程中会产生同名列，而QuestDB的查询模型不支持同名列共存

深层原因

根本原因在于SAMPLE_BY_REWRITE_WRAP_ADD_TIMESTAMP_COPIES标志的处理逻辑存在缺陷。该标志原本用于处理类似select timestamp a, timestamp b的多别名场景，但在处理计算列时：

1. 父查询的时间计算列（如timestamp+60000000）错误地依赖于子查询的timefloor(timestamp)结果
2. 查询模型重构过程中，计算依赖关系被破坏
3. 列处理顺序导致最后一列被意外丢弃

解决方案建议

针对该问题，建议从以下几个方向进行修复：

1. 依赖关系分析：在重写查询模型时，需要完整保留计算列的依赖关系链
2. 列唯一性检查：确保查询模型重构不会产生同名列
3. 边界条件测试：特别关注包含时间计算、多列选择和分组操作的组合场景

总结

这个问题展示了数据库查询优化器中一个典型的重写逻辑缺陷。它提醒我们，在处理SQL语法树转换时，必须特别注意：

• 计算表达式的完整依赖关系
• 中间结果的正确传递
• 查询模型转换的边界条件

对于使用QuestDB的开发人员，在遇到类似列丢失问题时，可以暂时通过以下方式规避：

1. 避免在SAMPLE BY查询中对时间戳列进行计算
2. 或者将计算逻辑移到应用层处理
3. 增加冗余列保证所需列不被丢弃

该问题的修复将提升QuestDB在处理复杂时间序列查询时的稳定性，特别是对金融、物联网等需要精确时间计算的场景尤为重要。