SQL数据库执行引擎调度_算子流水线设计_网络技术

SQL执行引擎采用拉模式迭代器为基础，关键路径结合批处理与推式传递；调度器解耦并支持就绪优先、亲和性、反压感知等策略；物化点依数据特征动态设置，流水线并发与并行正交设计。

SQL数据库执行引擎的调度与算子流水线设计，核心在于让多个物理算子（如Scan、Filter、Join、Agg）高效协同，避免阻塞、减少中间数据落盘、提升CPU和I/O利用率。关键不是“串行等结果”，而是“数据驱动、分批流动、异步协作”。

主流执行引擎（如PostgreSQL、Doris、Trino）多采用**迭代器模型（拉模式）**：上层算子调用next()向下游拉一行/一批数据。优点是控制流清晰、内存友好、易于暂停/中断；缺点是函数调用开销略高、难以自动重叠I/O与计算。

部分高性能引擎（如HyPer、ClickHouse的部分Pipeline执行器）采用**推模式**：下游算子准备好后主动向上游注册回调，上游读到数据即推送。优势是更易实现算子间零拷贝传递、天然支持并行扇出/扇入、利于CPU流水线填充。

实际设计建议：

传统执行器常把调度逻辑耦合在算子树遍历中；现代引擎则将**调度解耦为独立组件**，负责决定“此刻该让哪个pipeline片段运行”。它不关心SQL语义，只关注资源状态与数据就绪性。

典型调度策略包括：

并非所有算子都适合全程流水——有些必须攒够数据才能开始（如Sort、HashAggregate、WindowFunction）。这时需明确划分**pipeline segment**，并在边界处插入**物化点（Materialization Point）**。

物化不是“全写磁盘”，而是选择合适载体：

关键原则：物化点由数据特征（cardinality、skew、order需求）驱动，而非固定语法节点。例如，即使SQL写了ORDER BY，若优化器确认输入已按该字段局部有序且内存足够，可跳过全局Sort，改用归并式流式排序。

流水线内并发（intra-pipeline）与流水线间并行（inter-pipeline）需分离设计：

避免常见陷阱：不要让一个算子同时承担“多线程锁竞争”和“跨pipeline资源争抢”，应通过无锁环形缓冲区、分片内存池、work-stealing队列等方式隔离。