从两个实例看出我们国产数据库厂商与国外头部厂商的差距

这两天Oracle停止俄罗斯的数据库销售与服务的事情让国产数据库又掀起了一场狂欢。几年前拉里的Oracle跟随美国政府惩罚维瑞内拉大多数人可能都不太关注，而当这个问题落到大国头上，可能会让我们放弃掉最后一丝幻想了。在关键核心系统上数据库国产化替代的工作无论如何都是势在必行了。

去O这种利国利民的事情为什么提出了快十年了，还只是流于表面，没能像小型机替代那么摧枯拉朽呢？从大道理上大家都认为“势在必行”的事情，为什么到了实际的工作中就变成了“恐怕不行”呢？这主要还是源自我们自己的产品还不够争气，存在差距。这种差距是全方位的，在去年的一个闭门专家会上，大家都谈了很多这方面的问题。

实际上，如果知道差距，承认差距，努力去弥补差距，我们的这项工作是一定会成功的。如果真的是这样，那么在核心系统中实现数据库国产化替代就只是时间的问题了。现在就是怕我们不肯面对差距，装聋作哑的不愿意看到差距，或者说我们的水平不足，看不到差距。那样的话，我们的国产数据库追赶世界先进水平的路就会变得更长了。

说到看清差距的问题，我在去年的会上也谈了一些。这两天我遇到的一件事情，让我看到了一个更深层次的差距，而且这个差距目前我们和国外头部厂商之间相比较，就太大了，而且在越拉越大。

前两天我和一个朋友在讨论一个Oracle数据库的十分奇怪的问题，在一份100053 trace里我们看到了一个十分奇怪的现象，SQL语句被莫名其妙的做了一次谓词内推（FPD）的转换，在SQL上莫名其妙的增加了一个基于函数索引的谓词断语。这种SQL REWRITE后，甚至语义都变了，SQL的执行结果都会出错了。当时我们觉得莫名其妙，到MOS上搜索了一下，发现基本上都是BUG，而且这些BUG的最终结果都是SQL结果出现了错误。我也没有仔细去阅读这些BUG报告。两天后，Lewis大师给出了回复，这是Oracle的一个正常行为，目的是为了提高CBO的能力。看到大师的回复我才恍然大悟，仔细想想，真的让我惊出一身冷汗，一个产品居然能做的如此细致，而这个功能的出现已经是十多年前了。

其实今天我们可以十分简单的来重现这个案例。

我每次查询之前都会刷新buffer cache，从而确保数据缓冲对这两个查询之间的影响是一样的。这两个查询的差异是比较快的查询在t_date_1上有一个条件。而t_date_1上并没有索引。我们可以通过下面的SQL来验证一下。

那为什么这两个查询的执行效率为什么会不同呢？我们来对比一下这两个查询的执行计划。

从这里我们可以看出这两条语句的执行计划的差异了。第二条语句居然使用了索引。而我们前面看到了在where条件的字段上是没有索引的，而IDX_1这个索引在前面的查询中看到也和T_DATE_1无关，是一个SYS_NC00005$上的索引。这种字段实际上是一个虚拟字段，我在这张表上创建了一个SUBSTR(T_DATE_1,1,10)的索引，这个虚拟字段就是指的这个。如果这么一看，我们确实可以看出来，这个索引是有效的，可以加快此类查询的性能。

实际上，Oracle在实现这种执行策略，就采用了那个前面我说过的莫名其妙的FPD TRANSFER。通过10053 trace，我们可以看到其实现的细节。

可以看出，CBO在生成执行计划的时候，采用了一个十分巧妙的方法，首先把这条SQL改写了，让这条SQL上多了一个AND SUBSTR("TEST_A"."T_DATE_1",1,8)='20220112'的条件，这样最终生成执行计划的时候，正确的选择了上面所说的执行计划。当然最终执行SQL的时候，FILTER还是使用了WHERE条件中的过滤器。

从这个案例我们可以看出很多值得我们学习的地方。首先是Oracle在产品上下的细致的工作，这种极小概率出现的应用场景被他们捕捉到了，这需要有大量的案例，以及对每个客户的反馈的认真总结才能具有的能力。其次是他们在架构设计上的水平，这种实现方式看似笨拙，实际上十分高明，在CBO中对这种场景设计一个FPD规则（实际上这不是一种典型的FPD场景）就可以利用原来的功能实现这个功能需求，而不需要对CBO进行深度的改造。这可以看出ORACLE在这方面的老到，这些都是值得我们去学习的。

另外一个例子是昨天发生的，我们的一个客户数据库遇到一个BUG，出现了HANG死的情况。我通过MOS很快就找到了一个类似的案例，为了进一步确认，让Oracle的朋友帮我下载一下完整的SR报告。过了一会儿朋友问我，怎么给我这份报告。我说发微信不就行了。他说不行，整个SR下载下来200多M。我拿到这份沉甸甸的报告一看，实际上分析定位问题只占了报告的前面不到10%的内容，后面都是后续内部各个部门分析诊断，以及讨论如何更好的解决这个问题的内容。从这份严谨的态度，我们也能看出成功是如何得到得了。

如果说目前我们国产数据库厂商得研发只能说差强人意，与国外大厂之间还存在较大的差距，那么如果比比售后，这种差距可能比月亮要遥远的多了。实际上售后并不是成本，对于一个数据库这样复杂的产品来说，能把售后服务变成促进产品成长的生产力，这方面，我们和国际大厂比，差距就更大了。

只有充分重视产品在实际客户中的使用体验，不断的通过努力去改善客户体验，我们的产品才会越做越好。Oracle的这种从客户的故障中获得产品改善的需求的做法绝对是我们必须学习的。比较一下Oracle的产品经理，再回头看看我们的产品，差距可能会越看越大。前者子我们的一个国产数据库的系统账号密码忘记了，找厂家问一个找回的方法，厂家说如果是用我们的图形化工具安装的，那么就可以用工具重置，否则就只能重建数据库了。似乎这也给出了一个合理的解决方案，不过如果和Oracle来对比，那就是天差地别了。这实际上是一种对产品不负责的态度。如果客户有一个关键系统，确实忘记了超级管理员密码，而恰恰没有按照你建议的方法去按照部署，那么就只能重建数据库了吗？好的产品肯定会去满足客户的各种需要，而不是让客户必须按照你的玩法来玩。

希望我今天说的两个小故事，能给我们的国产数据库厂商一些启示。