SQL数据库向量化执行通过列式批处理、SIMD并行、延迟物化等硬件协同优化，显著加速分析查询；其核心是重构数据流以适配现代CPU特性，而非简单批量处理。
SQL数据库的向量化执行通过批量处理数据、减少函数调用开销和提升CPU缓存利用率，显著加快分析型查询（如聚合、过滤、JOIN）的执行速度。核心不是单纯“一次处理多行”，而是围绕现代硬件特性重构执行引擎的数据流与计算模式。
向量化执行的关键设计特征
传统火山模型（Volcano Iterator）以逐行（row-at-a-time）方式拉取数据，每行触发多次虚函数调用、分支预测失败和缓存不友好访问；向量化执行则采用列式批处理（batch-at-a-time），典型批大小为1024或2048行：
- 列式内存布局：同一列数据连续存放，利于SIMD指令（如AVX-512）并行计算（如同时比较16个int32）
- 消除虚函数调用：运算符内联展开，避免迭代器模式中的间接跳转开销
- 延迟物化（Late Materialization）：先在轻量级位图（bitmap）上完成过滤/JOIN匹配，最后才构造完整结果行，大幅减少中间数据搬运
- 流水线融合（Pipeline Fusion）：相邻算子（如Filter + Project）合并为单个循环，避免中间batch拷贝
批处理性能提升的实际来源
性能增益并非来自“批”本身，而源于批带来的硬件协同优化机会：
- CPU指令级并行增强：编译器可对固定大小batch生成更优汇编（循环展开、寄存器复用），LLVM JIT常用于动态生成专用代码
- 减少分支误预测：批量条件判断（如WHERE age > 30）可转为掩码操作（mask = _mm256_cmpgt_epi32(age_vec, threshold_vec)），避免每行一次分支
- 降低内存带宽压力：列式+压缩（如RLE、Dictionary）使同等数据量下实际加载字节数减少3–5倍，缓解内存瓶颈
- 异步I/O与计算重叠：一个batch在CPU计算时，下一个batch可由DMA预取进L3缓存，隐藏I/O延迟
主流数据库的实践差异
不同系统对向量化的实现深度和适用场景有明显区别：
- ClickHouse：全栈向量化（Parser → Planner → Interpreter → Functions），支持运行时JIT编译表达式，对宽表聚合性能优势极明显
- StarRocks / Doris：MPP架构下各BE节点本地向量化执行，结合智能谓词下推与Runtime Filter，适合高并发Ad-hoc查询
- PostgreSQL（via Vectorized Extension）：作为插件提供有限向量化（仅部分Scan/Agg算子），需手动启用，兼容性优先于极致性能
- SQL Server（Batch Mode）：仅在列存储索引（Columnstore）上自动启用，行存仍走传统模式，依赖硬件加速器（如Intel DL Boost）提升某些函数性能
使用建议与注意事项
向量化不是银弹，效果高度依赖数据特征与查询模式：
- 优先用于分析型大表扫描（>1M行）、高选择率过滤（WHERE条件能快速剪枝）、简单聚合（SUM/COUNT/GROUP BY字段少）
- 避免在频繁点查（SELECT * FROM t WHERE id = ?）、复杂UDF（未向量化实现）、深度嵌套JSON解析等场景强依赖向量化
- 监控关键指标：CPU周期/行（应明显下降）、L3缓存命中率（应上升）、IPC（Instructions Per Cycle，理想值接近3–4）
- 批大小需权衡：太小（如128）无法摊薄开销，太大（如8192）易导致L1/L2缓存失效；多数系统默认1024–2048，生产环境建议压测调整
