本文作者：聿明，毕业于电子科技大学，OceanBase高级技术专家，现主要负责DML相关的研发工作
本节为源码解读的第八篇。前面在《SQL的一生》中介绍了SQL引擎各个模块。其中，执行引擎sql/engine是直接影响执行性能的，OB高性能执行引擎是怎么实现的？本文将介绍执行引擎，以及DML算子的设计。
前七篇可参考：
1、OceanBase 数据库源码解读（一）引言
2、OceanBase 数据库源码解读（二）目录结构
3、OceanBase 源码解读（三）SQL 的一生
4、OceanBase 源码解读（四）分区的一生
5、OceanBase 源码解读（五）事务的一生
6、OceanBase 源码解读（六）租户的一生
7、OceanBase源码解读（七）带你看透虚拟表
比较特别的是，当前执行引擎有两套实现，还在过度阶段，他们有什么区别呢？
SQL执行器的代码位于src/sql/engine目录下
和大多数经典的数据库做法类似，OceanBase执行引擎采用了volcano迭代模型，一条SQL被解析成一颗plan tree，组成plan tree的节点在OB中被称为算子(operator)，engine目录下的子目录定义了执行相关的具体算子。
执行器代码中可以看到每个operator有两种不同的名字
这是因为在OB的版本迭代过程中，执行器框架经历过一次大的重构，在目前的版本中，新的执行引擎并未在功能上完全替代旧的执行引擎，因此存在两种执行引擎并存的状态，在代码中，每个operator的名字后带op后缀的是新引擎代码，反之为旧引擎代码，新旧引擎主要有两个不同点：
1.旧引擎的表达式执行为弱类型结构，表达式的计算类型是在执行阶段根据输入参数动态确定的，动态选择表达式的计算路径；新引擎的表达式执行为强类型结构，表达式计算类型在编译阶段确定，并在编译阶段确定计算接口，表达式计算阶段只根据编译阶段确定好的函数指针进行调用即可，这样可以减少很多动态判断，表达式计算更加高效
2.旧引擎的数据迭代过程会动态分配每一行数据的内存，因此在数据迭代过程中，一些需要物化的operator需要进行内存拷贝，而新引擎中operator的内存在计算开始前被统一预分配，因此在执行阶段避免了数据迭代的拷贝
执行算子的设计采用了静动态数据分离的模式，静态部分在生成执行计划阶段确定好，并且在整个执行计划的生命周期内不会再发生变化，因此静态部分的数据结构可以被同一种SQL的不同参数形式并发访问，而动态数据记录的是每条SQL的执行状态，这部分数据是每个query私有的部分，不能被其它query共享；静态数据逻辑在旧引擎中位于ObPhyOperator以及其派生的各个具体的子类中，在新引擎中位于ObOpSpec以及其派生的具体子类中；动态数据逻辑在旧引擎中位于ObPhyOperatorCtx以及其派生子类中，在新引擎中位于ObOperator以及其派生子类中；ObPhysicalPlan中定义了执行计划相关的一些静态全局数据结构以及逻辑，ObPhysicalPlanCtx定义了执行计划相关的动态全局数据结构；
具体Operator说明
在DML模块中，对于同一种insert操作可以看到有两个相似的文件定义：
DML对应的操作分为两套算子，Multi-Part xxx和Table xxx，其中Multi-Part Insert是用来处理多分区的insert操作，而TableInsert是用来处理单分区的insert操作，其它DML操作也是类似关系，Multi-Part DML operator实际上是一个调度单分区operator的微调度器，它只负责对数据按分区进行重分布，并不负责将具体的数据写入到存储层，具体的写入操作Multi-Part DML是通过将对应的数据封装成一个单分区的Table DML操作来完成的，他们的对应关系为：
好了，以上就是第八期关于执行引擎，以及DML算子的设计全部的解读了。
（未完待续，一起期待第九期）
最后的最后：
如果您有任何疑问，都可以通过以下方式与我们进行交流：
测试遇到问题?
企业用户想享受技术顾问的免费一对一咨询服务？
点击右边→加入 OB 创计划
钉钉群：33254054
