SQL执行引擎采用拉模式迭代器为基础，关键路径结合批处理与推式传递；调度器解耦并支持就绪优先、亲和性、反压感知等策略；物化点依数据特征动态设置，流水线并发与并行正交设计。
SQL数据库执行引擎的调度与算子流水线设计，核心在于让多个物理算子（如Scan、Filter、Join、Agg）高效协同，避免阻塞、减少中间数据落盘、提升CPU和I/O利用率。关键不是“串行等结果”，而是“数据驱动、分批流动、异步协作”。
算子流水线的本质：拉模式 vs 推模式
主流执行引擎（如PostgreSQL、Doris、Trino）多采用**迭代器模型（拉模式）**：上层算子调用next()向下游拉一行/一批数据。优点是控制流清晰、内存友好、易于暂停/中断；缺点是函数调用开销略高、难以自动重叠I/O与计算。
部分高性能引擎（如HyPer、ClickHouse的部分Pipeline执行器）采用**推模式**：下游算子准备好后主动向上游注册回调，上游读到数据即推送。优势是更易实现算子间零拷贝传递、天然支持并行扇出/扇入、利于CPU流水线填充。
实际设计建议：
- 默认以拉模式构建基础迭代器接口，保障可组合性与调试性
- 在关键路径（如Scan→Filter→Project）启用“批处理+向量化+推式传递”，例如一次拉取1024行，内部用SIMD过滤后整批移交，不逐行调用
- 跨线程/跨阶段调度时（如HashJoin Build侧与Probe侧），必须引入显式缓冲区与背压机制，防止内存爆炸
调度器角色：从简单轮询到动态优先级驱动
传统执行器常把调度逻辑耦合在算子树遍历中；现代引擎则将**调度解耦为独立组件**，负责决定“此刻该让哪个pipeline片段运行”。它不关心SQL语义，只关注资源状态与数据就绪性。
典型调度策略包括：
- 就绪优先（Ready-First）：维护一个就绪队列，任何算子完成I/O或消费完输入批次后即入队，调度器取头执行
- 亲和性调度：将同一pipeline的算子尽量绑定到同一线程或L3缓存域，减少跨核数据迁移
- 反压感知调度：当某算子输出缓冲区使用率超阈值（如80%），降低其上游调度频率，甚至插入微睡眠
- 代价引导调度：结合优化器预估的算子耗时与当前系统负载（CPU/IO等待率），动态调整并发度或切片大小
流水线分段与物化点控制
并非所有算子都适合全程流水——有些必须攒够数据才能开始（如Sort、HashAggregate、WindowFunction）。这时需明确划分**pipeline segment**，并在边界处插入**物化点（Materialization Point）**。
物化不是“全写磁盘”，而是选择合适载体：
- 小结果集 → 内存块（chunked vector）
- 中等结果集 → spillable hash table 或排序缓冲区（带LRU淘汰）
- 大结果集 → 本地临时文件 + mmap读取 + 异步预取
关键原则：物化点由数据特征（cardinality、skew、order需求）驱动，而非固定语法节点。例如，即使SQL写了ORDER BY，若优化器确认输入已按该字段局部有序且内存足够，可跳过全局Sort，改用归并式流式排序。
并发与并行的正交设计
流水线内并发（intra-pipeline）与流水线间并行（inter-pipeline）需分离设计：
- Intra-pipeline：单个JOIN可拆为多个probe task并行执行，共享build侧哈希表（只读），各自维护probe状态
- Inter-pipeline：多个独立查询或同一查询的不同分区（如scan on partition A/B/C）作为独立pipeline提交给调度器
- 两者共用同一套内存池与CPU配额，由调度器统一仲裁——例如限制单查询最多占用2个硬件线程，但允许其内部4路probe并发
避免常见陷阱：不要让一个算子同时承担“多线程锁竞争”和“跨pipeline资源争抢”，应通过无锁环形缓冲区、分片内存池、work-stealing队列等方式隔离。
