GreptimeDB 中特定场景下 ORDER BY 查询未使用窗口排序的性能问题分析

问题背景

在 GreptimeDB 分布式时序数据库的实际使用中，我们发现某些包含 ORDER BY 子句的查询未能利用高效的窗口排序（WindowedSort）机制，而是退化为普通的全量排序（SortExec），这在处理大规模数据时会导致显著的性能差异。

现象观察

通过对比以下两类查询的执行计划，我们可以清晰地看到性能差异：

1. 高效执行计划（使用窗口排序）：

SELECT * FROM orderby_test ORDER BY greptime_timestamp DESC LIMIT 10

执行计划显示使用了WindowedSortExec和PartSortExec的组合，这是专为分布式环境优化的有限排序机制。

2. 低效执行计划（使用全量排序）：

SELECT greptime_timestamp AS timestamp FROM orderby_test ORDER BY greptime_timestamp DESC LIMIT 10

执行计划显示使用了SortExec和SortPreservingMergeExec的组合，这意味着需要先对所有数据进行排序再取前N条。

技术根因分析

经过深入代码分析，发现问题核心在于查询计划中的投影（Projection）操作与排序操作的"可交换性"判断逻辑：

1. 可交换性机制：GreptimeDB 通过Commutativity特性来判断操作是否可以下推。当前实现中，Expr::Alias（列别名表达式）被标记为Unimplemented，导致包含别名的查询无法应用窗口排序优化。

2. 分布式环境复杂性：在分布式模式下，Substrait 查询计划转换会引入临时列名（如t__temp__0），这使得现有的窗口排序规则无法正确识别时间索引列。

3. 安全边界考虑：原始设计将别名表达式统一视为不可交换是出于保守考虑，因为别名可能用于子查询等复杂场景，盲目下推可能导致语义错误。

解决方案探讨

针对这个问题，我们可以考虑以下改进方向：

1. 精细化别名处理：

   • 对于简单的列引用别名（如t AS ts），可以安全地将其视为可交换操作
   • 保留对复杂表达式别名的保守处理

2. 分布式计划适配：

   • 增强窗口排序规则对临时列名的识别能力
   • 在分布式计划转换阶段保持必要的列语义信息

3. 优化器增强：

   • 引入更智能的交换性判断规则
   • 为时序查询添加特殊优化路径

性能影响评估

窗口排序优化可以带来显著的性能提升：

• 内存使用：从需要缓存全表数据变为只需维护TopN的窗口
• 网络传输：分布式环境下大幅减少节点间数据传输量
• 执行时间：避免不必要的全量排序计算

总结与展望

这个问题揭示了分布式数据库查询优化中计划转换与本地优化的微妙交互。GreptimeDB 作为新兴的时序数据库，在处理这类问题时需要在正确性与性能之间找到平衡点。未来可以通过以下方向持续改进：

1. 建立更完善的交换性判断体系
2. 增强优化器对分布式特性的感知能力
3. 为时序查询设计专属的优化规则

这个问题也提醒我们，在数据库系统设计中，语法糖（如列别名）的实现可能会对查询性能产生深远影响，需要在设计初期就充分考虑其优化器交互。