开辟分布式查询性能提升的路径，OceanBase 4.0 到底做了哪些改变？

早在2021年 5 月份，OceanBase 3.x 版本中的OceanBase 就在TPC-H中占据性能排行首位，数据库核心性能的每小时执行请求数综合指标达到了 1526 万QphH@30,000GB，但这样的成果对于OceanBase 来说，还不满足。通过对部分业务场景中遭遇到的问题加以剖析，OceanBase 开始思考应该如何改进 SQL 引擎来提升分布式查询性能。

通过全方位、多渠道的分析，OceanBase 认为当前主要面对的是如何战胜分布式查询优化中提升了计划枚举空间、需要维护更多的物理属性以及更加精准的分布式代价模型等多重挑战。前者既要关注单机和分布式的实现，又要应对算子序和分区信息的复杂性；后者既要考虑 CPU 和 IO 的代价，还要考虑网络传输代价、查询的并行度以及一些分布式特定优化场景的代价。

多阶段环环相扣，OceanBase 4.0完善分布式查询优化方法

切中问题后，OceanBase 为了解决分布式查询优化带来的复杂性，逐步完善分布式查询优化方法。先假设所有的表都是本地的，依赖已有的单机查询优化能力选择一个本地最优的执行计划；再在固定连接顺序和本地算法的基础上，基于简单的分布式代价模型为每一个算子选择一个分布式算法。

但这还不能满足OceanBase 的需求，在此基础上，OceanBase 4.0 重构了整个分布式查询优化方法，从原先的二阶段变成了一阶段的分布式查询优化方法。即给定一个 SQL 语句，System-R 用 bottom-up 的动态规划的方法来进行连接枚举和连接算法的选择；给定一个 N 张表的连接，该方法以 size 为驱动枚举每一个子集的执行计划。

其中，枚举所有单机的连接算法，维护序物理属性，使用单机代价模型来计算代价；保留代价最小的计划和存在有用序的计划，一个计划的序是有用的当且仅当该序对后续算子的分配有用。同时，OceanBase 使用分布式代价模型来计算代价，护序和分区信息这两个物理属性。

通过不同阶段的具体举措，OceanBase 4.0 大大减少了分布式计划空间，提升了分布式查询优化的性能。

多举措层层递进，OceanBase 4.0提升分布式执行引擎性能

在执行引擎方面，OceanBase 4.0 制定了多方面的举措，并且相继推进，其中包括实现了新的分布式和单机算法，完善了整个向量化引擎的实现，开发了极致的并行下压技术，开启了自适应技术的开发。

具体来说，就是OceanBase认为一个执行引擎发展到一定阶段一定要通过自适应技术来尽量解决优化器产生的不优的执行计划的问题。其在OceanBase 4.0 执行引擎开始朝着自适应的方向发展，即执行引擎根据当前的执行状态来识别出来一部分计划不优的场景，通过动态调整执行计划从而达到提升执行性能的目的。

与此同时，OceanBase 4.0 实现了自适应的 Group by/Distinct 并行下压技术，它可以解决Group by/Distinct 并行下压场景中因为计划不优而导致的性能回退问题，核心思想是提前把 Group by 算子下压下去做部分的数据预聚合，通过预聚合的方式可以减少网络传输从而达到提升性能的目的。

另外，OceanBase 4.0 还进一步探索和实现更多新的自适应技术，包括自适应的创建和探测 bloom filter、自适应地调整 nested loop join 和 hash join，自适应地调整分布式的 broadcast 连接和分布式的 hash-hash 重分区连接等技术，从而将 OceanBase 的执行引擎能力提升到一个新的级别，最终朝着极致的并行下压技术的方向发展，达到持续提升性能的目的。

时至今日，OceanBase 4.0 出于我们对客户需求的理解和对自己对分布式系统的理解，实现了全新的分布式代价模型和分布式查询优化框架、开发了一套非常完善的并行下压技术，开启了自适应技术的开发。

未来，OceanBase 在已经取得显著成就前提下，还将继续以“数据库的本质是基础软件”为核心理念，站在软件「使用者」的角度，在未来的 4.x 版本中，继续通过分布式查询优化和执行引擎技术的创新能力，帮助用户带来更易用的使用体验和更快速的查询性能。