本文分享自华为云社区《GaussDB AP是如何执行SQL的》，作者：yd_270088468。
前言
介绍GaussDB AP各组件是如何协调工作的，会着重介绍SQL引擎。
1、SQL引擎组件和SQL生命周期
Parser: 词法/语法分析模块。词法分析会从SQL字符串中解析出一个个单词，作为语法分析的输入。语法分析可以想象成是一个"正则表达式"，但远比正则表达式复杂，它定义了所有SQL类型的语法规则以及操作符的优先级和结合律。语法分析结束后，会生成一个Parse Tree，作为语义分析模块的输入。比如一个SQL是SELECT id,data FROM tbl_a WHERE id < 300 ORDER by data;,语法解析生成的Parse Tree如下所示：
Analyzer: 语义分析模块。语义分析会访问数据库中的对象，检查表是否存在、列是否合法，并将表、排序列、投影列等转化为内部对象ID。另外，它还会检查SQL语义是否正确合法，比如Aggregate函数在where子句中是不合法的。经过语义分析后，Parse Tree会转化成Query Tree，作为查询重写模块的输入。Query Tree的结构与Parse Tree有点类似，但在内容上更加丰富，包括Query Tree保存的是数据库内部的对象信息、多了一些Flag标记等。语义分析生成的Query树如下所示：
Rewriter: 查询重写模块。查询重写模块会根据用户定义的规则对查询进行重写，实际是对Query Tree中的成员进行修改或者替换。Rewrite过程如下所示：
Planner: 优化器模块。优化器的输入是Query Tree，输出Plan Tree，用来指导执行器执行，比如如何join，如何扫描数据，如何排序等。
Executor: 执行器模块。根据优化器输出的Plan Tree，进行初始化、执行，执行的时候会调用存储引擎的接口，这里不做展开。
2、SQL执行整体架构
步骤一：业务通过ELB下发SQL给CN，SQL可以是DDL，DML，DCL。
步骤二：CN判断SQL类型，如果SQL类型是DDL/DCL，不用生成plan，将SQL发送到其他CN和所有DN，在所有CN/DN上执行。如果SQL类型是DML，对于不需要使用stream算子的（可以分成3小类），会将SQL直接发给各DN执行，对于需要使用stream算子的，会生成plan下发给DN执行。
步骤三：DN执行DML过程中，可能会从其他DN获取数据，DWS提供了三种stream算子（Redistribute/Broadcast/Gather），降低数据在DN节点间的流动。
步骤四：DN将结果集返回给CN进行汇总。
步骤五：CN将汇总后的结果返回给业务。
3、DDL在CN/DN如何交互
3.1 单DDL的情况
3.2 并发DDL的情况
为了避免并发DDL造成死锁，默认开启enable_parallel_ddl，控制从所有CN下发的DDL都使用同一个CN作为起点开始执行。
消息序列图说明
前提：CN 1，CN 2，CN 3上各收到一条对表test进行DDL操作的请求。CN 1为被选定的第一个执行DDL的节点。
T1：CN 2不是第一个执行DDL操作的节点，所以CN 2将Command 2命令发送给第一个执行的节点CN 1，然后等待CN 1回复；
T2：CN 3也不是第一个执行DDL操作的节点，所以CN 3将Command 3命令发送给第一个执行的节点CN 1，然后等待CN1回复；
T3：CN 1是第一个执行DDL操作的节点，故按基线原有逻辑执行，即先在本地执行；
T4：CN 1执行Command 2，对表test拿锁。Command 2执行完成后，CN 1告知CN2：Command 2在我上面已经完成。此时，Command 1和Command 3拿不到锁，处于等待状态。
T5：CN 2收到CN 1的Command 2执行完毕的回复之后，给CN 3发送command 2命令，等待CN 3的回复。
T6：CN 3执行command 2，回复执行结果给CN 2；
T7：CN 2将command 2发送给DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；
T8：DN1，DN2，DN3分别在本地执行Command 2，回复CN 2执行结果；
T9：CN 2本地执行Command 2，成功后提交，至此集群中所有的CN和DN全部放锁，Command 2执行完毕。
T10：CN 1执行Command 3，对表test拿锁。Command 3执行完成后，CN 1告知CN3：Command 3在我上面已经完成。此时，Command 1拿不到锁，处于等待状态。
T11：CN 3收到CN 1的Command 3执行完毕的回复之后，给CN 2发送command 3命令，等待CN 2的回复。
T12：CN 2执行command 3，回复执行结果给CN 3；
T13：CN 3将command 3发送给DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；
T14：DN1，DN2，DN3分别在本地执行Command 3，回复CN 3执行结果；
T15：CN 3本地执行Command 3，成功后提交，至此集群中所有的CN和DN全部放锁，Command 3执行完毕。
T16：CN 1将Command 1发送给CN2，CN3，并等待他们的回复；
T17：CN2，CN3分别在本地执行Command 1，回复执行结果给CN 1；
T18：CN 1将command 1发送给DN1，DN2，DN3，要求它们在本地执行并等待他们的回复；
T19：DN1，DN2，DN3分别在本地执行Command 1，回复CN 1执行结果；
T20：CN 1本地执行Command 1，成功后提交，至此集群中所有的CN和DN全部放锁，Command 3执行完毕。
从上面实现可以看到，其中心思想是将多CN上并发的DDL操作串行化，即指定一个最先执行的CN，所有的DDL都必须先在这个CN上执行完成后才可以在别的节点上执行。这样的话，在这个被指定的CN上面，DDL操作就是串行的，拿不到锁的DDL会等待，但不再会出现拿不到锁的死锁情况。
4、DML执行计划生成
4.1 CBO模型
CBO: Cost-Based Optimization也即"基于代价的优化器"，相对于RBO（Rule-Based Optimization），CBO对数据很敏感，执行计划更灵活，当数据量变化的时候，CBO往往能生成更优的执行计划。
CBO 的基本优化流程：搜索引擎利用转换规则，对输入的逻辑执行计划进行(逻辑/物理)转换，构造出执行计划的搜索空间。之后，利用代价模型对搜索空间中的每一个执行计划进行代价估算，选出代价最低的物理执行计划。而代价估算的过程离不开基数估计：它利用各个表、列的统计信息，估算出各算子的输入行数、选择率等信息，提供给算子的代价模型，从而估算出查询计划的代价。
DWS优化器是基于代价的优化器（CBO），它可以为每一条SQL构造出搜索空间，并根据数据的统计信息、基数估计、算子代价模型，为搜索空间中的执行机计划估算出执行所需要的代价(CPU/MEM/IO/NET)，最终选出代价最小的执行计划作为SQL的具体执行方式。
4.2 搜索空间
采用Cascade（动态规划）/GEQO（遗传基因）的方式进行计划搜索。通过Cascade算法可以实现精确计算，但时间复杂度高，适用于表连接较少的情况。GEQO是非精确计算的方法，适用于表很多的情况。
4.3 统计信息
包括逻辑表的行数，列的非重复值数（NDV），列Null值信息等。
4.4 基数估计
基数估计会估算各个算子中间结果的行数或基数等信息，例如Join输出行数，Agg会产生的Group数量等等。
4.5 算子代价
对于同类算子，将所有实现算子的消耗（代价）均计算出来，选择代价最小的。
输入：两个表的大小、Join列的数据特征、有序性、可用内存大小work_mem；
输出：算子的代价（消耗时间的维度）
4.6 分布式计划
前3个计划都是CN下发语句给DN，第4个计划是CN生成计划，将计划下发给DN，第4个计划也被称为stream计划，是最为常用的计划。
为什么会有下发语句的计划？
CN生成执行计划，需要耗费较多CPU资源，且计划较原始语句大许多，下发语句对于CN以及网络传输的开销小很多。