DuckDB中row_number()与rowid的性能差异分析与优化方向

在数据库系统中，行标识符是数据处理中的基础操作。DuckDB作为一款高性能的分析型数据库，提供了两种获取行标识的方式：rowid伪列和标准SQL窗口函数row_number() OVER ()。本文将深入分析这两种方式的性能差异及其背后的技术原理。

性能对比实验

通过一个简单的基准测试可以观察到显著的性能差异：

• 创建包含10亿行的测试表
• 使用row_number() OVER ()过滤前10行耗时约2.5秒
• 使用rowid过滤前10行仅需20毫秒

这种百倍的性能差距主要源于执行计划的差异。rowid作为底层存储的物理标识符，其过滤条件可以直接下推到表扫描阶段，避免了不必要的数据处理。而窗口函数row_number()需要构建完整的执行流水线，计算所有行的序号后才能应用过滤条件。

技术实现差异

DuckDB中这两种行标识的实现机制存在本质区别：

1. rowid伪列：

   • 直接映射到存储引擎的物理行标识
   • 查询优化器可以识别并下推相关谓词
   • 存在间隙（如删除操作后rowid不连续）
   • 是DuckDB特有的实现

2. row_number()窗口函数：

   • 标准的SQL语法
   • 需要完整的窗口函数计算流程
   • 保证连续编号（不考虑数据修改）
   • 跨数据库兼容性更好

优化方向探讨

虽然当前性能差异明显，但DuckDB团队已经注意到这个问题并考虑以下优化方案：

1. 查询优化器增强：识别特定的row_number() OVER ()模式，将其转换为类似rowid的物理计划
2. 存储层集成：在扫描阶段直接生成连续行号，避免额外的计算开销
3. 混合执行策略：对于有序表扫描，可以增量计算行号

使用建议

在实际应用中，开发者可以根据场景选择合适的方式：

• 追求极致性能且能接受rowid特性的场景：使用rowid
• 需要标准SQL兼容性或连续编号的场景：使用row_number()
• 期待未来版本优化后，可以统一使用标准语法

DuckDB作为持续演进的数据库系统，这类性能优化将逐步缩小语法糖与标准SQL之间的性能差距，为用户提供既符合标准又高性能的使用体验。