留给CBO优化器的弯道不多了

​前几天一个做数据库产品的朋友和我聊起在国产数据库上的弯道超车问题，他觉得对于通用关系型数据库，Oracle已经领先太多了，如果不弯道超车，国产数据库永远没有机会赶上Oracle。弯道超车一直被很多朋友看作是超越的捷径，不过我认为弯道超车一定是以实力作为后盾才能够完成的。要想弯道超车，后车的引擎必须高于前车，至少是二者相当，没有实力做保障，弯道技术再好，也是很难完成超车的。

在通用关系型数据库领域，想要对Oracle实现弯道超车，大家都会选择CBO优化器。AI4DB是被大家寄予厚望的。通过AI算法的辅助来纠正执行计划中的错误，或者帮助某条SQL选择一个更好的执行计划。其主要方法是基于历史数据的分析，通过一定的参数（比如表分析数据、历史执行计划的效率等），通过算法计算执行计划的成本，在重大决策中辅助CBO的规则引擎，比如当HASH JOIN和NESTED LOOP经常会选错的时候，通过AI算法辅助，让CBO选择的执行计划更为准确。

实际上Oracle这些年也一直CBO上发力，动态CURSOR是Oracle用于解决这个问题的方法，当SQL在执行过程中发现NESTED LOOP成本过高的时候，自动将目前的执行暂停，更换为HASH JOIN，从而避免某些SQL出现严重的性能问题。只不过Oracle目前的算法还不够完善，因此动态CURSOR有时候还会出错。

Oracle的CBO优化器是基于数据模型的优选算法的，其主要方法是通过各种统计数据，对某个SQL的不同算子计算成本，最后将一条SQL的各种执行方式的成本都算完后，选择其中成本最低的执行计划去执行。这种方法也是目前绝大多数数据库系统分析执行计划的基础算法。到目前的版本为止，Oracle并没有选择通过AI算法来获得执行计划，而是继续沿用其传统的算法。不过随着Oracle的数十年的发展，其CBO优化器的核心算法基础上，已经积累了大量的补丁，这些补丁都是对核心主算法的纠正，在Oracle内部被称为FIX。每个FIX实际上就是一个特殊场景下SQL选择执行计划中的修正模型，都是在实战中遇到问题后，标准CBO算法无法解决问题时的一种特殊处理，也可以称为经验模型。此外，Oracle还将其中的一些特别重要的修正进行了特殊的处理，设置了一些隐含参数加以控制。这些修正往往不是CBO优化器的不足，而是在不同的应用场景中，特殊的用户数据与用户硬件环境可能导致CBO优化器产生错误的选择，通过这些参数可以加以调整。其中最为著名的莫过于optimizer_index_cost_adj，这个参数可以调整CBO优化器在计算索引扫描时的成本，在二十年前的Oracle 8i/9i时代，我们经常通过调整这个参数来避免不必要的对全表扫描的错误选择，让数据库更倾向于使用索引扫描。

在Oracle 11.2.0.4中，CBO优化器的可调整参数有329个，FIX有846个。到了19.15.0.0版本，CBO优化器可调整参数的数量高达612个，FIX的数量达到了1369个。实际上每个FIX后面都有无数个用户的痛苦经历，是Oracle数据库的CBO优化器在用户环境中遇到了问题后的修正。

Oracle数据库的优化器是十分优秀的，这一点大家都是公认的，但是其优秀的优化器依然无法解决所有的用户的问题，依然需要不断的通过添加参数来做更精细的控制，甚至加入某些特殊的修正来解决问题。

目前我们国产数据库的优化器恐怕还在重点完善CBO优化器的核心算法，还没有遇到过如此多的实战案例，发现那么多主逻辑可能存在的问题。这些参数与FIX必须是在大量的实战中获得的，因此有些国产数据库厂家想另辟蹊径了。通过AI4DB是不是可以绕开这个问题，实现在CBO上的弯道超车呢？恐怕有此想法的朋友要失望了，CBO优化器是基于统计数据与算法规则的，历史的SQL执行情况可以提供参考，但是无法作为下一次解析SQL时的可靠依据。因为数据在不断的变化，参数也在变化，而CBO优化器的每次解析，都决定了SQL语句是否能够合理的执行。一次错误的解析很可能引发一场灾难。因此AI算法在这个场景中可以起到辅助发现SQL问题的作用，但是无法替代规则来生成执行计划。我们的CBO优化器也只能在实战中不断的经受挑战，不断的经历痛苦的折腾，才能变得越来越强大。当我们的优化器的FIX和可调整参数能够达到Oracle的时候，才真正算是成熟了。CBO优化器成长的最佳途径是在实战中不断完善，而不是凭着我们的研发人员的想象力，在家里闭门造车。

先不要空谈弯道超车，扎扎实实的在用户厂家中去修炼，把优化器一点点做好吧，实际上在现阶段，能够先远远的跟上最先进的数据库产品，已经是国产数据库的成功了。