在现代分析型数据库领域，向量化执行与列式存储已成为提升查询性能的关键技术路径。DuckDB 作为一款面向嵌入式分析场景的列式数据库，其内核设计充分体现了这两项技术的深度融合。理解 DuckDB 如何在内存中组织数据、如何在执行层面批量处理元组，对于数据库内核学习者而言，是一次不可多得的工程实践机会。本文将从向量批次设计、向量格式体系、列式存储架构三个维度，拆解 DuckDB 的核心执行机制。

向量化执行的核心：STANDARD_VECTOR_SIZE 与 DataChunk

传统行式数据库采用逐行执行模型（Row-at-a-Time），每条元组单独经过算子链处理，这种模式在分析型查询场景下极易成为性能瓶颈。DuckDB 选择了向量化执行路线，其核心思想是将数据组织为固定大小的列向量批次，算子一次处理数百至数千条元组，从而最大化 CPU 缓存命中率并为 SIMD 指令优化提供条件。

在 DuckDB 的源代码中，STANDARD_VECTOR_SIZE 被定义为 2048，这意味着每个向量默认容纳 2048 个元组。这一数值的选择并非随意，而是经过多重权衡的结果：2048 个元素恰好能够充分利用现代 CPU 的 L1/L2 缓存（以 8 字节元素计，2048 × 8 = 16KB，接近 L1 缓存行大小），同时又足够大以摊销函数调用和循环控制的开销。当需要处理更大规模的数据时，DuckDB 会将数据切分为多个 2048 元组的批次依次处理。

DataChunk 是 DuckDB 执行层的核心抽象，它是一个向量容器，聚合了查询结果的一行或多列。以一个三列投影查询为例：SELECT col1, col2, col3 FROM table，其执行过程会生成一个包含三个向量的 DataChunk，每个向量分别存储对应列的 2048 个值。算子并非逐行读取数据，而是以 DataChunk 为单位进行拉取（Pull-Based）操作，上游算子产出 DataChunk 后传递给下游算子消费，整个查询计划的数据流动本质上是 DataChunk 的流水线传递。

向量格式体系：Flat、Constant、Dictionary 与 Unified Vector Format

DuckDB 的向量系统设计极具特色，它支持多种物理表示方式来适配不同的数据分布特征，这种能力直接支撑了执行层面的压缩优化。

Flat 向量是最基础的格式，以连续内存数组存储数据，逻辑位置与物理位置一一对应。对于均匀分布的列数据，Flat 向量提供了最高的访问效率，算子可以直接通过索引计算偏移量获取目标值。Constant 向量则用于存储重复值，当表达式计算结果为常量（例如字面量或常量列）时，DuckDB 仅存储单个值而非重复 2048 次，这在函数求值阶段能够显著减少内存占用和计算量。举例而言，执行 SELECT 'duckdb' || col FROM tbl 时，字符串字面量 'duckdb' 被表示为 Constant 向量，仅在第一次计算时完成拼接操作，随后直接广播给所有 2048 个输出位置。

Dictionary 向量是 DuckDB 实现运行时压缩的关键机制。当列数据存在大量重复值时（例如低基数列），字典压缩会将唯一值存储在子向量中，同时用选择向量（Selection Vector）记录每个位置对应的唯一值索引。这种格式的优势在于：即使原始数据未经显式压缩存储，在执行过程中也能保持压缩状态进行计算，避免了解压缩的额外开销。DuckDB 在从磁盘读取字典压缩的列段时，会直接将数据加载为 Dictionary 向量，实现从存储到执行的无缝衔接。

面对多种向量格式的组合爆炸问题，DuckDB 引入了 Unified Vector Format（统一向量格式）。当算子需要对不同格式的向量进行统一处理时（例如聚合函数接收 Flat 和 Constant 混合输入），统一向量格式提供了一种通用的 “视图” 抽象：它将各类向量转换为统一的逻辑结构，包含指向数据缓冲区的指针、选择向量以及有效数据长度。这种设计使得算子实现无需针对每种向量组合编写特化代码，在保持执行效率的同时大幅降低了工程复杂度。

列式存储与复杂类型：string_t 与嵌套结构

在列式存储层面，DuckDB 针对不同数据类型设计了差异化的内存布局。对于字符串类型，DuckDB 实现了 string_t 结构体以平衡短字符串的存储效率与长字符串的灵活性：长度不超过 12 字节的字符串会被直接内联到结构体中（inlined 形式），而超过 12 字节的字符串则使用指针指向堆分配的辅助缓冲区。这种设计避免了短字符串的额外指针间接访问开销，同时通过长度字段避免了 strlen 调用，前缀字段（prefix [4]）则用于快速字符串比较的早期退出。

对于 List、Struct、Map、Union 等复杂类型，DuckDB 同样采用了列式嵌套表示。List 向量由 list_entry_t 结构体（含 offset 和 length 字段）与子向量组合而成，每个列表的起始位置和长度信息与实际数据分离存储；Struct 向量则由多个子向量组成，子向量的数量和类型由结构体的模式定义。这种嵌套表示方法使得 DuckDB 能够在保持列式优势的同时，优雅地处理层次化数据。

实践参数与监控要点

理解 DuckDB 向量化执行机制的工程参数，有助于在调优场景中做出更精准的决策。首先，threads 参数控制并行执行的工作线程数，默认值通常等于 CPU 核心数，在向量化执行框架下，每个线程独立消费 DataChunk 并行处理，因此将线程数设置为物理核心数而非逻辑核心数，往往能获得更稳定的性能表现。其次，vector_size 参数在较新版本中支持调整，但通常建议保持默认的 2048，因为过大的批次会破坏缓存局部性，过小的批次则增加调度开销。

监控层面，可通过 EXPLAIN ANALYZE 查看查询计划的算子耗时分布，关注是否存在大量数据在单一算子处堆积的情况，这可能暗示向量批次在各阶段间的传递效率受限。在向量格式层面，若查询计划中出现大量 Dictionary 向量转换或解压缩操作，意味着数据分布可能具备更高的压缩潜力，可考虑在存储层启用字典压缩或调整列的编码方式。

综合来看，DuckDB 的向量化执行引擎通过 2048 固定批次大小、多格式向量系统、统一抽象层三项核心设计，在工程层面实现了高效的分析型查询处理。这些设计选择并非孤立的技术决策，而是性能、内存与代码复杂度之间权衡的产物。对于数据库内核学习者而言，深入理解这些工程细节，远比泛泛阅读数据库原理更具实操价值。

参考资料