客户应用中遇到问题的地方就是国产数据库的发力点

​因为一大早有个合作伙伴前来交流，客户库所以昨天的应用文章实际上是匆匆发出来的，并没有完整的中遇表达出我对这个问题的看法。今天在外面出差，到问地方点本来和客户约好上午见面，国产因为临时的数据安排问题，又改到下午了，发力所以早上有比较充裕的客户库时间来写一写昨天想表达的另外一层意思。

表连接的应用性能关系到绝大多数管理信息系统的性能问题，而最常用的中遇表连接方式就是NESTED LOOP和HASH JOIN。当HASH JOIN还不成熟的到问地方点时候，NESTED LOOP是国产主打，不过对于一些左表返回数据较多或者说找不到一张返回数据量较少（比如小于几百）的数据左表的情况下，SQL的发力性能是很差的。HASH JOIN让一些大查询的香港云服务器客户库性能得到了有效的优化。不过HASH JOIN也不是任何时候都有效的，如果原本使用NESTED LOOP的连接被错误的选择为HASH JOIN，会带来巨大的不必要的扫描开销，也会影响SQL的执行时间。因此选择适当的表连接方式对于SQL性能来说十分关键。

昨天在我的测试中存在问题的执行计划，实际上都是企业的信息系统中很常见的SQL产生的，这些SQL在Oracle中表现都是很好的，而当使用某些开源数据库或者国产数据库时才会出现问题，这也反映出我们的国产数据库在优化器上与Oracle的差距。优化常见表连接的执行计划的能力，b2b供应网实际上应该作为国产数据库十分重要的一项工作来做。

SQL解析过程中都会有SQL REWRITE这个阶段，实际上我们遇到的很多SQL的执行计划有问题，都是在这个阶段没能改写出更优的SQL来，所以后续的执行计划生成就会陷入到优化器的缺陷中了。优化器的改进是个十分艰苦的过程，其难度巨大，PG数据库这些年虽然版本迭代很快，但是优化器中的几个顽疾一直没有解决掉（昨天我举的例子中的执行计划存在问题的地方，都是PG优化器由来已久的顽疾），这也充分说明了优化器核心提升的难度。

不过SQL REWRITE这个阶段与优化器的核心之间相对独立（当然其中关联也十分紧密），因此优化SQL REWRITE阶段的能力可以作为数据库厂商优先发力的企商汇地方，能够把一个优化器较难处理的SQL改写出一个比较容易处理的SQL，那么某些老大难的问题就不需要动优化器的核心，也能够解决问题了。

一年期我写过一篇文章《从两个小例子看我们的差距》，其中一个是我们以前讨论过的一个ORACLE CBO优化器的例子。在一份100053 trace里，我看到了一个十分奇怪的现象，SQL语句被莫名其妙的做了一次谓词内推（FPD）的转换，在SQL上莫名其妙的增加了一个基于函数索引的谓词断语。刚开始的时候，我认为这种SQL REWRITE后，甚至语义都变了，SQL的执行结果都有可能不对了，Oracle CBO为什么要做这样的FPD呢。后来经过分析发现SQL有个WHERE  ADATE=’20210102 122103’ 这样的条件，不过ADATE上并无索引，不过存在一个substr(ADATE,1,8)索引。按理说这个索引不会被使用，不过这个场景下，使用函数索引能够有效地提高SQL的效率。而在Oracle的核心优化器中增加这方面的能力将会是一个大改动，于是Oracle巧妙的添加了一条FPD规则，对此类SQL通过规则进行一次简单的改写，优化器对于处理此类Sql的性能就大大提高了。

最近这一年里，做了大量的数据库国产化替代相关研究与测试工作，我发现现在绝大多数国产数据库都在高唱秒杀一切的性能，优秀的TPC-C/TPC-H指标，不过我们的用户的实际体验是应用从Oracle迁移下来以后大量的SQL执行性能下降数十倍甚至数百倍。基于这些应用体验，我觉得我们的国产数据库厂商真的需要在这些“小地方”多下点功夫，能够让用户用得更爽。因为我们用户的应用场景中，超过99%的场景是普通的管理信息系统，而不是超高并发，超高交易量的TPMC场景。能够踏踏实实把用户最需要的日常问题都解决好了，用户的应用开发，应用迁移成本都降低了，自然使用你的产品的用户就会越来越多。

最新评论