共计 1527 个字符，预计需要花费 4 分钟才能阅读完成。
家喻户晓，执行器执行之前，须要打算的撑持。打算分为逻辑打算和物理打算。他们的关系就好比是咱们要进来游览，抉择什么交通工具就相当于逻辑打算，在这一步比方抉择了飞机后，抉择哪家航空公司就相当于物理打算。最初，当你真正出发去游览就相当于执行。
上面给出 SQL 语句执行的根本构架图，从中能够分明地看到优化器和执行器在整个流程中的执行过程。
优化器
逻辑打算和物理打算负责生成执行打算和索引抉择等性能，能够把它看做优化器。比方执行这样的语句，执行两个表的 join：
Select * from t1 join t2 using(ID) where t1.c = 10 and t2.d = 20既能够先从 t1 里取出 c =10 记录的 ID，再依据 ID 关联到 t2, 再判断 t2 外面 d 的值是否等于 20，也能够先从 t2 里取出 c =20 记录的 ID，再依据 ID 关联到 t1，再判断 t2 外面 d 的值是否等于 10。这两种执行办法的逻辑是一样的，但执行效率不同，优化器能够预估代价决定应用计划。在分布式数据库中，其中的物理打算还能够依据要用到的数据 span 所在的节点判断该算子在哪个节点上执行，从而实现分布式执行。与分布式相干的物理打算具体作用在分布式执行概述。
分布式执行
分布式执行的要害思维是如何从逻辑执行打算到物理执行打算，这里次要波及两方面的解决，一个是计算的分布式解决，一个是数据的分布式解决。
一旦生成了物理打算，零碎就须要将其拆分并散布到各个 node 之间进行运行。每个 node 负责本地调度 processors 和 inputs。node 还须要可能彼此通信以将输入 output router 连贯到 input。特地是，须要一个 streaming interface 来连贯这些组件。为了防止额定的同步老本，须要足够灵便的执行环境以满足下面的所有这些操作，以便不同的 node 除了执行打算初始的调度之外，能够绝对独立的启动相应的数据处理工作，而不会受到 gateway 节点的其余编排影响。
数据库的集群中的 Gateway node 会创立一个调度器，它承受一组 flow，设置输出和输入相干的信息，创立本地 processor 并开始执行。在 node 对输出和输入数据进行解决的时候，咱们须要对 flow 进行一些管制，通过这种管制，咱们能够回绝 request 中的某些申请。
每个 Flow 示意整个物理打算中跨节点执行的一个残缺片段，由 processors 和 streams 组成，能够实现该片段的数据拉取、数据计算解决和最终得数据输入。如下图所示：
对于跨节点得执行，Gateway node 首先会序列化对应得 FlowSpec 为 SetupFlowRequest，并通过 GRPC 发送到远端 node，远端 node 接管后，会先还原 Flow，并创立其蕴含得 processor 和交互应用得 stream（TCP 通道），实现执行框架得搭建，之后开始由网关节点发动驱动得多节点计算。Flow 之间通过 box 缓存池进行异步调度，实现整个分布式框架得并行执行。
对于本地执行，就是并行执行，每个 processor，synchronizer 和 router 都能够作为 goroutine 运行，它们之间由 channel 互联。这些 channel 能够缓冲信道以使生产者和消费者同步。
为实现分布式并发执行，数据库在执行时引入了 Router 的概念，对于 JOIN 和 AGGREGATOR 等简单算子依据数据分布特色，实现了三种数据再散布形式，mirror_router、hash_router 和 range_router，通过数据再散布实现 processor 算子外部拆分为两阶段执行，第一阶段在数据所在节点做局部数据的解决，解决后后果，依据算子类型会进行再散布后，第二阶段会集解决，从而实现了单个算子多节点合作执行。
