查询处理四阶段流水线：解析/重写/优化/执行

一条SQL语句从提交到返回结果，要经过四个职责分明的阶段，每个阶段 把上一阶段的产出转换成下一阶段更容易处理的形式。查询解析用词法 分析器和语法分析器（类似编译原理里编译其他高级语言的做法），把SQL 字符串转换成语法树——这一步只关心语法是否合法，不关心怎样执行更快。 查询重写把语法树转换成一个（或一组）关系代数表达式：展开视图定义、 拆解子查询（因为带子查询的查询往往执行效率低，需要拆成”先执行子 查询、再执行父查询”的多个步骤）、拆分聚集计算（先取原始数据再计算， 本身就是两步）——重写的产物是与原SQL语义完全等价、但表达形式更 利于后续优化的关系代数表达式序列。查询优化在保证语义不变的前提下 寻找执行代价更低的方案，分代数优化（用等价规则调整关系代数运算的 顺序和组合，属于逻辑层面的调整）和物理优化（为每个逻辑运算选择 具体的存取路径和算法，如选择运算是用全表扫描还是索引扫描，属于 落地到具体执行方式的调整）两步，最终生成查询执行计划。查询执行 根据这份执行计划，用相应的算法组件（全表扫描、索引扫描、各种连接 算法等）组装成实际的执行流水线，跑出结果。数据字典（表结构、索引 定义、数据统计信息等元数据）在重写和优化两个阶段都要被频繁查阅， 是这条流水线能做出合理决策的信息基础。

结构图：

flowchart LR
    A[SQL语句字符串] --> B[查询解析<br/>词法+语法分析]
    B --> C[语法树]
    C --> D[查询重写<br/>视图展开/子查询拆分/聚集拆分]
    D --> E[关系代数表达式]
    E --> F[查询优化<br/>代数优化+物理优化]
    F --> G[查询执行计划]
    G --> H[查询执行<br/>组装算法组件跑出结果]
    I[数据字典: 元数据+统计信息] -.支持决策.-> D
    I -.支持决策.-> F