迭代模型的流水线拉取执行机制

查询执行引擎不是把每个操作算完整个结果集再交给下一个操作，而是把 关系代数中的每种操作抽象成一个独立的操作模块，组装成一棵查询操作树， 按迭代模型（也叫火山模型、流水线模型）来运行——这也是大多数关系 数据库（SQLite、PostgreSQL、Oracle、MySQL等）采用的执行方式。这套 模型的核心特征是”自顶向下调用、自底向上拉取数据”：查询操作树按需求 驱动方式执行时，根节点向下层请求一个（或多个）元组，若下层没有现成 数据则继续向更下层请求，请求一路传导到叶子节点（如TableScan直接从 数据文件读取），叶子节点产生的数据再一路向上传递、逐层加工，直到 根节点拿到最终结果——因为这种”要一个给一个”的拉取方式，也称为拉取 执行模型。它的好处是每个操作模块可以独立实现、互不干扰，且相邻操作 之间只需要传递单条元组而不是整批结果，不需要为中间结果分配大块内存， 这对内存受限的场景很友好。代价是效率：每次只处理一条元组意味着 调用底层接口的次数非常多，CPU在频繁的函数调用和上下文切换上花费 不少开销，而且连接、排序这类需要”等齐所有输入才能开始输出”的操作 天然会阻塞整条流水线，无法真正做到边读边算边输出。这个”简单但调用 开销大”的权衡，是后来出现向量化执行、批处理等替代模型的直接动因 （本书未展开，仅点出迭代模型本身的取舍）。