在上一期的「带你走进 SQL 引擎」课程中，相信你已经学习到了 SQL 引擎的基础知识，对 SQL 在各模块间的流动也有了整体的认知。在 SQL 引擎包含的模块中，SQL 执行引擎作为其最终落地的“手脚”，负责执行优化器给予的执行计划，通过存储引擎读取数据并进行处理后，将结果返回给客户端。因此，执行引擎能够直接影响 SQL 的执行性能。
9月15日 19:30 内核实战教程第五期 将带你了解 SQL 执行引擎的基本理论知识及 OceanBase 的执行引擎实现，你可以深入了解一款企业级分布式数据库如何实现执行引擎的高性能及如何做到毫秒级地增删改查。通过本期** OceanBase 执行引擎实现过程**的学习，对于想参加 OceanBase 数据库大赛及想从事 SQL 层研发的同学都会有很大的帮助。
本期能帮你解决什么问题？
1、OceanBase 作为企业级原生分布式数据库，并行执行能力是如何实现的。
2、OceanBase 是如何实现向量化执行引擎的。
3、MiniOB 实战手把手系列之 MiniOB Date 类型实现解析。
直播内容抢“鲜”知
在上一期，你已经了解了 SQL 引擎的各个知识点，我们知道查询优化器将SQL语句解析并从执行计划中选择最低消耗的执行计划后，具体的执行就会交由执行引擎，那么SQL执行引擎如何设计与实现呢？本期内容通过介绍OceanBase的SQL执行引擎的实现，为你详细讲解。
OceanBase的SQL执行引擎经过多年演进，从传统的火山模型，由单行迭代执行演进为向量化执行，极大地提升了单核执行能力。同时，由于其具备SQL并行执行的能力，可以充分利用系统资源并行处理用户请求，从而降低RT。
从图1可见，OceanBase 第二代执行引擎延续了传统的火山模型，数据按行迭代，但对旧的执行引擎进行了重写。新的实现引入了强类型计算，执行内存预分配，使用表达式列表描述行信息，将静态的meta信息与数据分离，重新实现了表达式及算子计算框架，执行性能相比第一代执行引擎大幅提升。
图1 OceanBase SQL执行引擎演进历程
而从第二代的数据按行迭代到第三代向量化处理逻辑，产生了极大的优化。由于OceanBase 的用户场景除OLTP 类的简略查询外，还有报表剖析、业务决策等 OLAP 查询。而 OLAP 查询的数据处理量大、耗时高，传统的按行迭代模型每行都需要迭代一次，导致虚函数调用开销比较大，同时cache友好性也较差。为解决该问题, OceanBase 实现了向量化引擎。效果也很显著，在TPC-H 30T场景，向量化引擎的性能是非向量化的近3 倍，对于 Q1 这种聚合剖析且计算密集的 SQL 查询，性能提升约 10 倍。本次教程还会为你具体介绍更多OceanBase向量化实现细节。
图2 OceanBase 执行引擎之单行执行
图3 OceanBase 执行引擎之向量化执行
对于 OLAP 场景的 SQL 请求，需要分析大量用户数据，并且用户往往期望能够尽快给出结果，单核串行执行能力是有限的。为了能够尽快跑出结果，充分利用系统资源并行执行是关键。OceanBase 很早就实现了并行执行能力，可以支持大规模高并发处理，充分利用集群机器资源，在 TPC-H 30T 标准测试场景中，我们用64台机器的5120 个 CPU 超线程，同时去服务每一个用户请求，把本来需要几十分钟才能完成的请求在几秒内处理完。
图4 OceanBase 执行引擎之并行执行框架
OceanBase 是Share Noting 的分布式数据库架构，并行执行可以满足 AP 场景（数据量大，处理时间长）下对单个请求并发处理需求，但对于TP场景（耗时短，用户QPS高）， 一个SQL请求耗时可能只有几个ms甚至几百us, 一般都是串行执行（并行执行调度等开销相对TP耗时较大）。为了能够在分布式场景下高效处理TP场景请求, OceanBase提供了多种执行模式，包括本地执行、远程执行、DAS执行。
图5 OceanBase 执行引擎的多种执行模式
当前，OceanBase SQL执行引擎能够很好地满足用户对HTAP执行能力的需求，未来我们还将面向列存及新硬件进一步优化执行引擎能力。
更多详细内容，敬请关注 9月15日 19:30 「从 0 到 1 数据库内核实战教程」官方课程。
附录：
内核实战教程第一期 | 成为内核开发者的第一步：搭建研发环境
内核实战教程第二期｜带你揭开数据库存储结构的神秘面纱
内核实战教程第三期｜为什么索引可以让查询变快？
内核实战教程第四期｜带你走进数据库 SQL 引擎
课程回放
报名直播：https://open.oceanbase.com/activities/4921877?id=4921912