前几天有做数据库产品的朋友跟我聊起国产数据库上曲线超车的问题。他觉得对于通用的关系型数据库，甲骨文已经领先太多了。现在，如果没有弯道超车，国产数据库永远没有机会追上甲骨文。弯道超车一直被很多朋友视为超车的捷径，但我认为弯道超车一定要有实力做后盾。如果要在弯道超车，后车的发动机必须高于前车，至少要相等。没有实力做保障，你的过弯技术再好，也很难完成超车。在通用关系型数据库领域，想要弯道反超Oracle，大家都会选择CBO优化器。AI4DB备受大家期待。借助AI算法，修正执行计划中的错误，或者帮助某条SQL选择更好的执行计划。主要方法是在分析历史数据的基础上，通过一定的参数（如表分析数据、历史执行计划的效率等），通过算法计算执行计划的成本，辅助CBO规则引擎重大决策，比如当HASHJOIN时，NESTEDLOOP和NESTEDLOOP经常出错时，通过AI算法的辅助，CBO选择的执行计划更加准确。事实上，甲骨文这些年一直在CBO上下功夫。DynamicCURSOR是Oracle解决这个问题的方法。当SQL在执行过程中发现NESTEDLOOP的开销过高时，会自动暂停当前执行，代之以HASHJOIN，避免某些SQL出现严重的性能问题。只是Oracle目前的算法还不够完善，所以动态CURSOR有时会出错。Oracle的CBO优化器是基于数据模型的优化算法。它的主要方法是通过各种统计数据，计算出某条SQL的不同操作符的成本，最终计算出一条SQL的各种执行方式的成本，选择成本最低的执行计划执行。这种方法也是大多数数据库系统分析执行计划的基本算法。到目前为止，在当前版本中，Oracle并没有选择通过AI算法来获取执行计划，而是继续沿用其传统算法。但是Oracle经过几十年的发展，在其CBO优化器核心算法的基础上积累了大量的补丁。这些补丁都是对核心主算法的修正，在Oracle内部称为FIX。每一个FIX其实就是一个特殊场景下的SQL选择执行计划中的修正模型。是标准CBO算法在实战中遇到问题后无法解决问题时的一种特殊处理。它也可以称为经验模型。此外，Oracle还对一些特别重要的修正进行了特殊处理，并设置了一些隐式参数对其进行控制。这些修正往往不是CBO优化器的缺点，而是在不同的应用场景下，特殊的用户数据和用户硬件环境可能会导致CBO优化器做出错误的选择，这些参数是可以调整的。其中最著名的是optimizer_index_cost_adj，它可以在计算索引扫描时调整CBO优化器的成本。在20年前的Oracle8i/9i时代，我们经常调整这个参数来避免不必要的全表扫描的错误选择，使得数据库更倾向于使用索引扫描。在Oracle11.2.0.4中，CBO优化器有329个可调参数，FIX有846个。到19.15.0.0版本，CBO优化器可调参数达到612个，FIX达到1369个。其实每一个FIX背后都有无数用户的惨痛经历，这就是CBO之后的修正Oracle数据库的优化器在用户环境中遇到问题。Oracle数据库的优化器非常好，这是大家认可的，但是其优秀的优化器还是不能解决所有用户的问题，还需要不断的增加参数来做更细粒度的控制，甚至增加一些解决问题的特殊修复程序。目前我们国内数据库的优化器大概还是在专注于完善CBO优化器的核心算法。我们没有遇到那么多实战案例，发现主逻辑有这么多可能存在的问题。这些参数和FIX都是在大量实战中得来的，所以国内一些数据库厂商想另辟蹊径。能否通过AI4DB绕过这个问题，在CBO上实现弯道超车？恐怕有这种想法的朋友要失望了。CBO优化器基于统计数据和算法规则。历史SQL执行可以提供参考，但不能作为下一步SQL分析的可靠依据。因为数据在不断变化，参数也在不断变化，CBO优化器的每一次分析都决定了SQL语句是否能够合理执行。错误的解析很容易导致灾难。因此，AI算法可以辅助发现该场景下的SQL问题，但不能代替规则生成执行计划。我们的CBO优化器只有在实战中不断经受挑战，经历痛苦的??折腾，才能越来越强大。当我们的优化器的FIX和可调参数能够达到Oracle的时候，它就真正成熟了。CBO优化器最好的成长方式就是在实战中不断完善，而不是靠我们研发人员的想象闭门造车。不要光说弯道超车，而是要脚踏实地在用户工厂实践，把优化器做的再好一点。其实在现阶段，已经是能够跟得上最先进数据库产品的国产数据库了。的成功。
