因为一大早就有小伙伴过来交流，昨天的文章其实是匆匆发出来的，并没有完整的表达我对这个观点的看法问题。今天出差了，本来和客户约在上午的，但是因为临时安排的问题改到了下午，所以上午有更多的时间再写一层意思昨天想表白。表连接的性能关系到大部分管理信息系统的性能，最常用的表连接方式是NESTEDLOOP和HASHJOIN。在HASHJOIN还不成熟的时候，NESTEDLOOP是主要关注点，但是对于一些返回数据较多的左表或者找不到返回数据较少的左表（比如少于几百个），SQL的Performance较差。HASHJOIN有效地优化了一些大型查询的性能。然而，HASHJOIN并不总是有效。如果将原本使用NESTEDLOOP的连接错误的选择为HASHJOIN，会带来巨大的不必要的扫描开销，影响SQL的执行时间。因此，选择合适的表连接方式对SQL性能至关重要。我昨天测试出问题的执行计划，其实是用企业信息系统中很常见的SQL生成的。这些SQL在Oracle中表现非常好，而当使用一些开源数据库或者国产数据库时才会出现问题，这也体现了我们国产数据库在优化器方面与Oracle的差距。对commontablejoin的执行计划进行优化的能力其实应该作为国产数据库的一个很重要的工作来做。SQL解析的过程中会有一个SQLREWRITE的阶段。事实上，我们遇到的很多SQL执行计划都是有问题的。正是在这个阶段，我们还没有能够改写出更好的SQL，所以后续生成的执行计划就会陷入优化器的bug中。优化器的改进是一个非常艰巨的过程，而且极其难的。虽然PG数据库这几年版本迭代很快，但是优化器的几个顽固问题一直没有解决（我昨天举的例子中执行计划的问题，是PG优化器的老顽疾），这充分说明了优化器核心的优化难度。但是SQLREWRITE这个阶段和优化器的核心是相对独立的（当然也是非常紧密相关的），所以SQLREWRITE阶段的优化能力可以作为数据库厂商的优先考虑，可以优化优化器难以处理的SQL。重写一个相对好办的SQL，那么一些疑难问题就可以在不动优化器核心的情况下解决。一年前我写过一篇文章《从两个小例子看我们的差距》，其中一篇是我们之前讨论过的一个ORACLECBO优化器的例子。在100053trace中，我看到了一个很奇怪的现象。莫名其妙的把SQL语句转换成谓词推理（FPD），并且莫名其妙的给SQL增加了一个基于函数索引的谓词断言。一开始我以为这种SQLREWRITE之后，连语义都变了，SQL的执行结果可能是错误的。为什么OracleCBO会制定这样的FPD？后来经过分析，发现SQL有WHEREADATE='20210102122103'这样的条件，但是ADATE上没有索引，但是有substr(ADATE,1,8)索引。按理说这个索引是不会用到的，但是在这种场景下，使用函数索引可以有效的提高SQL的效率。将这种能力加入Oracle的核心优化器将是一个很大的改变，因此Oracle巧妙地增加了一条FPD规则，简单地重写了这类SQLpass规则。性能大大提高。在过去的一年里，我做了很多与数据库本地化相关的研究和测试。我发现国内的数据库大部分都是性能高歌猛进，TPC-C/TPC-H指标优秀。然而，我们很多用户的实际体验是，应用从Oracle迁移后，大量SQL执行的性能下降了几十倍甚至上百倍。基于这些应用体验，我觉得我们国内的数据库厂商确实需要在这些“小地方”上下功夫，让用户用起来更舒服。因为我们用户99%以上的应用场景都是普通的管理信息系统，而不是高并发、高交易量的TPMC场景。如果你能脚踏实地解决用户最需要的所有日常问题，用户的应用开发和应用迁移成本就会降低，自然会有越来越多的用户使用你的产品。
