内核处理流程 #

SphereEx-DBPlusEngine 内核处理流程包括标准的 SQL Parser 和 SQL Binder 模块，这两个模块用于 SQL 具体特征的识别，并根据其结果，将 SQL 执行流程分为 Simple Push Down Engine 和 SQL Federation Engine。

在微内核的流程中，SQL Parser 负责将用户输入的 SQL 通过 Lexer 和 Parser 的标准流程，转化为 AST (Abstract Syntax Tree) Node，并最终转化为提取必要特征的 SQLStatement，它是 Apache ShardingSphere 内核处理的核心输入。

SQLStatement 是 SQL 原义的体现，而 SQL Binder 则结合 Metadata 与 SQLStatement，补充 SQL 中的通配符和缺失部分，生成完整的符合数据库表结构的 AST Node。SQL Parser 通过分析 SQL 是否包含关联查询和子查询等基本信息，SQL Binder 则通过分析逻辑表和物理数据库的从属关系，最终确定 SQL 请求是否具备跨越多数据源操作的可能性。当 SQL 可以经过逻辑表修改、执行信息补全等操作即可以全文下推至数据库存储节点时，采用 Simple Push Down Engine，用于保证 SQL 的最大兼容度；反之，当 SQL 涉及跨库关联和跨库子查询时，则采用 SQL Federation Engine，用于在分布式表关联的操作中获取更加的性能。

Simple Push Down 下推流程 #

Simple Push Down 下推流程由 SQL 解析 => SQL 绑定 => SQL 路由 => SQL 改写 => SQL 执行 => 结果归并 组成，主要用于处理标准分片场景下的 SQL 执行。

在经过了标准的 SQL Parser 和 SQL Binder 前置流程后，SQL Router 会提取 SQLStatement 中的关键字段（如：分片键），并与用户通过 DistSQL 配置的具体规则相匹配，计算最终路由的数据源。

在知晓数据所在的数据源之后，SQL Rewriter 负责将 SQL 改写为可以在分布式场景下直接下推到数据库执行的 SQL，比如逻辑表名替换、补列、聚合函数修正等。

SQL Executor 则根据当前请求的事务状态选择适合的执行引擎，并将改写完成后的 SQL 以并发和分组的方式，发送至路由结果指向的数据源。 最终，当 SQL 的执行结果全部完成后，Result Merger 会自动将多个结果集进行聚合归并或进一步改写。

SQL Federation 执行引擎流程 #

SQL Federation Engine 与 Simple Push Down Engine 最大的不同在于 SQL Optimizer，它将 AST Node 通过 RBO（Rule Based Optimizer）和 CBO（ Cost Based Optimizer ）两种方式进行优化，生成 Query Plan Tree。

从存储节点中获取数据，并非通过原始 SQL，而是根据 Query Plan Tree 重新生成能够在单一数据节点执行的 SQL，并根据路由结果，发送至存储节点。在生成最终 SQL 之前，Query Plan Tree Rewriter 将根据用户通过 DistSQL 配置的规则对其中的表或列进行修改。值得注意的是，目标数据源并非必须与用户输入的 SQL 方言保持一致，可以通过 Query Plan Tree 生成适用于存储节点的全新 SQL 方言，比如： 其他数据库方言，甚至 Key-Value 等。

执行结果返回至 SphereEx-DBPlusEngine 的计算节点，并通过 Operator Calculator 在内存中进行最后的聚合计算，直至结果集最终返回。