课程导入：学习目标、适用人群、课程整体框架与学习路径
数据库执行引擎是查询处理的核心中枢，负责将 SQL 逻辑计划转化为物理操作序列并驱动数据流转。在传统火山模型（Volcano Model）中，每个元组（Tuple）在算子之间逐行传递，虚函数调用开销巨大，CPU 利用率长期徘徊在较低水平。随着现代 CPU 多级缓存、SIMD 指令集与多核架构的普及，向量化执行（Vectorized Execution） 已成为高性能分析型数据库（如 ClickHouse、DuckDB、Apache Doris、StarRocks）的标配技术。本课程旨在系统拆解执行引擎从行式迭代到批量向量处理的演进路径，深入剖析火山模型的性能瓶颈，并给出可落地的优化策略与工程实践。
1.1 学习目标：从“能跑”到“跑得快”
本课程的学习目标分为四个层次，层层递进，最终指向工程实践能力的全面提升。
| 层次 | 目标 | 可验证成果 |
|---|---|---|
| 第一层：理解 | 掌握火山模型与向量化执行的核心原理、差异及适用场景 | 能画出两种模型的算子调用时序图，解释性能差异根因 |
| 第二层：分析 | 能够使用性能剖析工具定位执行引擎瓶颈 | 能通过 perf 识别 next() 调用热点，量化缓存缺失率 |
| 第三层：实践 | 独立完成一个简单算子的向量化改造 | 实现 Filter/Project 算子的批量处理版本，性能提升 3 倍以上 |
| 第四层：设计 | 具备执行引擎架构选型与优化方案设计能力 | 能针对具体业务场景给出火山模型改造或向量化重写的技术建议 |
课程特别强调“可测量的性能提升”。每一章都会给出具体的性能指标（如 QPS、吞吐量、CPU 利用率、缓存命中率），并指导如何设计对照实验来验证优化效果。例如，在向量化改造章节，我们会使用 TPC-H 的 Q1 查询作为基准，对比行式迭代与批量处理在扫描 1 亿行数据时的耗时差异。
1.2 适用人群：谁需要这门课
本课程面向数据库内核研发工程师、基础架构工程师、以及对查询性能优化有极致追求的资深后端开发人员。具体包括：
- 数据库内核开发者：正在从事或计划从事 OLAP 数据库、数据仓库、湖仓一体引擎的开发工作，需要深入理解执行引擎的内部机制。
- 中间件/存储引擎开发者：工作涉及计算下推、表达式计算、数据扫描等模块，希望借鉴向量化思想优化自身组件。
- 性能优化工程师：负责大规模数据系统的性能调优，需要从执行引擎层面解决 CPU 密集型查询的瓶颈。
- 技术管理者/架构师：需要做技术选型或评估自研执行引擎的可行性，理解不同执行模型的优劣与改造成本。
学员需要具备的基础包括：扎实的 C/C++ 编程能力（至少能读懂模板与虚函数代码）、对 SQL 执行计划的基本认知（EXPLAIN 输出）、以及 Linux 环境下使用 perf/gprof 等工具的经验。如果对 CPU 缓存体系与 SIMD 指令有初步了解，学习效果更佳，但课程会在相关章节做必要铺垫。
1.3 课程整体框架：三大模块，三十章深度覆盖
课程内容划分为三个递进模块，每个模块内部章节按“原理 → 实现 → 案例 → 复盘”的逻辑组织。
模块一：火山模型原理与性能危机（第 1-8 章）。本模块从火山模型的经典实现讲起，分析其在大数据量下的性能瓶颈。重点包括：next() 虚函数调用的开销模型、CPU 分支预测失败的影响、行式内存布局对缓存友好度的破坏。通过一个模拟实验，学员将直观看到当数据量从 10 万行增长到 1 亿行时，火山模型的执行时间呈超线性增长，而向量化模型保持近似线性。
模块二：向量化执行引擎设计与实现（第 9-20 章）。这是课程的核心部分。从列式存储与批量处理的基本概念出发，逐步深入到 SIMD 指令的显式使用（如 AVX2 的 _mm256_cmp_ps）、算子的向量化实现（Filter、Join、Aggregation）、以及表达式编译执行（LLVM 动态代码生成）。每章都会提供可编译运行的代码片段，并给出性能对比数据。
模块三：优化策略与工程实践（第 21-30 章）。聚焦于真实系统中的优化技巧：如何在现有火山模型基础上渐进式引入向量化（而非推倒重来）、如何设计向量化友好的哈希表、如何处理变长字符串、以及如何利用多线程并行执行进一步压榨硬件性能。最后两章是完整的案例复盘：一个开源数据库（DuckDB）的向量化执行引擎拆解，以及一个自研引擎从火山模型到向量化的迁移实录。
1.4 学习路径与建议：如何高效掌握
考虑到学员背景差异，课程设计了三条学习路径：
- 速成路径（约 40 小时）：适合有丰富内核开发经验的工程师。跳过第 1-3 章的基础原理，直接从第 4 章“火山模型性能剖析”开始，重点学习第 9-15 章的向量化算子实现，最后完成第 28 章的实战项目。
- 标准路径（约 80 小时）：按章节顺序学习，每章完成课后练习与代码实验。这是推荐的完整学习方式，能建立系统性的知识框架。
- 研究路径（约 120 小时）：在标准路径基础上，额外阅读课程中引用的（如 MonetDB/X100、Peloton 的向量化执行研究），并尝试复现中的实验数据。
无论选择哪条路径，都建议遵循“动手验证”的原则。课程每一章都配有可运行的代码仓库（基于 C++17，无第三方依赖），学员应至少完成以下三个核心实验：
- 实验一：实现一个最小化的火山模型执行器（约 200 行代码），测量其处理 1000 万行数据的耗时。
- 实验二：将 Filter 算子改为批量处理模式，对比性能差异。
- 实验三：使用 AVX2 指令重写整数加法表达式计算，观察吞吐量变化。
1. 该技术解决了什么问题？
2. 它的代价或局限性是什么？
3. 如果我来实现，会怎么做？
带着这三个问题阅读，能显著提升知识留存率。
1.5 常见误区与学习心态
在长期的教学与工程实践中，我们发现学员在学习执行引擎优化时容易陷入几个误区，这里提前指出，帮助大家规避。
误区一：认为向量化就是“用 SIMD 指令”。实际上，SIMD 只是向量化的一种实现手段。向量化的核心是批量处理（Batch Processing） 与数据布局优化（Columnar Layout）。即使不使用任何 SIMD 指令，仅将逐行处理改为固定大小（如 1024 行）的批量处理，就能获得 2-3 倍的性能提升，因为减少了虚函数调用与改善了缓存局部性。课程会先讲批量处理，再讲 SIMD 加速，避免本末倒置。
误区二：盲目追求“全向量化”。并非所有算子都适合向量化。例如，嵌套循环 Join 在数据量小时，行式处理可能更快；某些复杂的用户自定义函数（UDF）难以向量化。成熟的数据库引擎（如 StarRocks）采用自适应执行策略：根据数据特征与硬件环境，动态选择行式或向量化执行路径。课程第 24 章会专门讨论这种混合执行模型。
误区三：忽略内存分配开销。向量化执行往往需要为每批数据分配内存。如果使用普通的 new/delete，内存分配开销可能抵消向量化的收益。课程会介绍内存池（Memory Pool）与 Arena Allocator 的设计，这是向量化引擎中容易被忽视但至关重要的组件。
误区四：只关注 CPU 而忽略 IO。执行引擎的优化必须与存储格式协同。如果数据存储在行式文件中，向量化执行前需要先进行列式重组，这部分的开销可能超过执行本身的收益。因此，课程第 18 章专门讲解列式存储格式（如 Parquet）与执行引擎的接口设计。
最后，关于学习心态，建议保持“从问题出发”的思维方式。不要先背结论，而是先问：为什么火山模型慢？慢在哪里？是 CPU 周期浪费了，还是内存带宽不足？带着具体问题去阅读代码和实验数据，才能真正理解优化的本质。课程每一章都会以一个具体的性能问题开场，引导大家思考解决方案，再逐步展开分析。
总结而言，本课程的目标是让你不仅知道“向量化更快”，更理解“为什么快”、“快多少”、“代价是什么”、“何时适用”。通过 30 章的系统学习与动手实践，你将具备独立分析、设计和优化执行引擎的能力。现在，让我们从火山模型的性能瓶颈开始，踏上这段充满挑战与收获的优化之旅。