DuckDB查询执行机制深度解析：临时表与CTE的性能差异

概述

在使用DuckDB进行数据分析时，开发者经常会遇到查询性能差异的问题。本文将通过一个实际案例，深入探讨DuckDB中临时表(Temporary Table)和公共表表达式(CTE)在执行机制上的本质区别，以及它们对查询性能的影响。

问题现象

在DuckDB中执行相同逻辑的查询时，开发者观察到了显著的性能差异：

1. 使用临时表方案时：

   • 单纯执行查询耗时约40ms
   • 查询后转换为DataFrame耗时约43.5ms

2. 使用CTE方案时：

   • 单纯执行查询仅耗时79μs（看似500倍性能提升）
   • 但转换为DataFrame后耗时又回到约33.8ms

底层机制解析

这种性能差异源于DuckDB的查询执行模型：

1. 查询计划构建阶段

当调用db.sql()方法时，DuckDB仅构建查询计划(Query Plan)，而不会立即执行查询。这是一个轻量级的操作，主要涉及：

• SQL解析
• 语法树生成
• 逻辑计划优化
• 物理计划生成

2. 查询执行阶段

真正的查询执行发生在需要实际获取结果时，例如调用：

• .show() - 显示结果
• .df() - 转换为Pandas DataFrame
• .pl() - 转换为Polars DataFrame
• .arrow() - 转换为Arrow格式
• .fetchall() - 获取所有结果

3. 临时表与CTE的关键区别

临时表方案：

• 包含两个独立的SQL语句
• 第一个语句创建临时表并立即执行
• 第二个语句查询临时表
• DuckDB无法将两个语句合并优化

CTE方案：

• 是单个查询的一部分
• 整个查询可以作为一个单元进行优化
• 执行被推迟到真正需要结果时

性能差异原因

观察到的性能差异并非真实存在，而是测量方式导致的误解：

1. 当测量db.sql(query)时：

   • 对于CTE：仅测量了查询计划构建时间（微秒级）
   • 对于临时表：由于包含DDL语句，触发了部分执行

2. 当测量db.sql(query).show()或.df()时：

   • 都测量了完整的查询执行时间
   • 两种方案的性能差异变得合理

最佳实践建议

1. 理解惰性执行机制：

   • 明确区分查询计划构建和实际执行
   • 使用适当的测量方法（如%time print(db.sql(query))）

2. 选择适当的查询结构：

   • 对于复杂查询，优先使用CTE
   • 临时表更适合需要重复使用的中间结果

3. 性能优化方向：

   • 关注实际执行时间而非计划构建时间
   • 利用DuckDB的查询优化器优势

结论

DuckDB的查询执行模型采用了惰性评估策略，这种设计在提供灵活性的同时，也需要开发者理解其内部机制。通过本文的分析，开发者可以更准确地评估查询性能，并选择最适合特定场景的查询结构。记住，在分析性能时，应该关注实际执行阶段的耗时，而非仅仅是查询计划的构建时间。