SQL数据库在执行查询计划时，会把逻辑算子翻译成物理算子，并通过特定的调度方式在内存中流转数据。所谓算子执行模型，核心解决的是“谁来决定下一条数据什么时候产生、往哪里去”的问题。目前工业界最典型的两种答案是拉取式和推送式，它们对函数调用栈、CPU缓存命中率以及并行度设计都有深远影响。
拉取式执行模型的基本原理
拉取式（pull-based）模型也叫火山模型（Volcano model）的经典形态。在这个模型里，每一个算子都实现了一个类似next()的接口，上层算子需要数据时，就主动调用下层算子的next()方法。下层算子返回一条元组（tuple）或者表示耗尽的状态。控制流从上往下贯穿，而数据流则从下往上被“拉”出来，两者方向恰好相反。
这种模型的优势在于逻辑非常直观：优化器生成树状计划，根节点不断向下要数据，叶子节点（如表扫描）真正读取页面并返回。由于每次只处理一行，嵌套循环连接、递归查询等控制流复杂的算子很容易用拉取式表达。下面的伪代码展示了一个最简单的拉取式扫描与过滤：
// 拉取式扫描算子
class ScanPull {
private int cursor = 0;
private int[] data = {1, 2, 3, 4, 5};
// 上层调用next拉取一条
public Integer next() {
if (cursor >= data.length) {
return null; // 数据耗尽
}
return data[cursor++];
}
}
// 过滤算子，包裹扫描算子
class FilterPull {
private ScanPull scan;
public FilterPull(ScanPull s) { this.scan = s; }
public Integer next() {
Integer v;
// 不断向下拉取直到满足谓词
while ((v = scan.next()) != null) {
if (v > 2) return v;
}
return null;
}
}
拉取式的缺点同样明显：每次next()几乎都是一次虚函数调用，行级处理让CPU难以做批量预取，缓存局部性较差。在宽表、大批量聚合场景下，这种逐行跨层调用的开销会被放大。不过，由于其实现简单、易于调试，PostgreSQL、MySQL等传统关系库仍主要采用拉取式作为核心执行模型。
推送式执行模型的工作方式
推送式（push-based）模型把调度权交给了下层算子。叶子节点产生数据后，不等待上层来要，而是主动调用上层算子的consume()或push()方法把批次数据送上去。控制流与数据流方向一致，都是自底向上，因此更贴合现代CPU的流水线执行习惯。
在推送式里，算子通常以批（batch）或向量（vector）为单位交换数据，而不是单行。这样不仅能减少函数调用次数，还能让上层算子在一段连续内存上做向量化计算。以下伪代码说明了推送式的核心结构：
// 推送式接收接口
class OperatorPush {
public:
// 下层把一批数据推上来
virtual void push(const std::vector<int>& batch) = 0;
virtual void done() = 0;
};
// 过滤算子实现推送接口
class FilterPush : public OperatorPush {
OperatorPush* parent;
public:
FilterPush(OperatorPush* p) : parent(p) {}
void push(const std::vector<int>& batch) override {
std::vector<int> out;
for (int v : batch) {
if (v > 2) out.push_back(v);
}
// 主动推给上层
if (!out.empty()) parent->push(out);
}
void done() override { parent->done(); }
};
推送式在MPP（大规模并行处理）和向量化引擎中非常流行，例如一些分析型数据库会把整个管道（pipeline）编译成一段循环，彻底消除算子边界。但它对计划生成的复杂度要求更高：因为数据“自发”向上流，分支预测、背压（backpressure）和内存控制都需要在推送链里显式处理，否则容易出现一个算子推太快、上层来不及消费而爆内存的情况。
两种模型的对比与选型
从工程视角看，拉取式和推送式并非非此即彼。我们可以通过一张简表看清差异：
| 维度 | 拉取式 | 推送式 |
|---|---|---|
| 调度发起方 | 上层算子 | 下层算子 |
| 数据流方向 | 自下而上 | 自下而上 |
| 控制流方向 | 自上而下 | 自下而上 |
| 典型处理单位 | 单行 | 批次或向量 |
| 虚函数开销 | 高 | 低 |
| 背压实现 | 天然（不拉就不产） | 需显式控制 |
在OLTP点查、深层级关联查询中，拉取式的按需获取数据能减少不必要计算，且代码易于维护。而在OLAP大扫描、多列聚合场景，推送式配合向量化能把CPU利用率抬高一个量级。一些混合引擎会采用“拉取式框架套推送式管道”的思路：在顶层用拉取接口对接优化器，在底层热点管道内做推送式批量执行。
实际选型时，还要考虑执行计划的可重排性。拉取式因为上层掌握节奏，更容易做算子的惰性求值与短路；推送式则更适合把多个算子融合（fusion）成一个内核循环。理解这两种模型背后的控制权归属，是设计高性能SQL执行器的第一步，也是排查慢查询时判断瓶颈在“取数慢”还是“算得快但推不动”的关键。
小结与落地建议
拉取式和推送式本质上是控制流与数据流关系的两种安排。拉取式以简单和灵活见长，推送式以吞吐和局部性取胜。如果你在自研数据库或改造执行引擎，建议先梳理查询中哪些算子是瓶颈：若是表扫描后紧接过滤与聚合，用推送式批处理收益最大；若是多层相关子查询，保留拉取式更稳妥。也可以参考现有开源实现，在单机引擎里用拉取式快速验证语义，再针对宽表分析路径插入推送式向量管道，逐步迭代而非一次性重写。
SQL_executorpull_basedpush_based修改时间：2026-08-10 00:21:36