昨天关于NESTED LOOP BATCHING的文章，有朋友说这是执行计划选择错误，而不是笛卡尔积的问题。实际上此类SQL性能问题，都是因为统计数据而选错了执行计划。
昨天谈到的问题是因为NESTED LOOP BATCHING的存在，让NLJ的执行计划选择变得更为复杂了，NESTED LOOP BATCHING有三个行源，两层NESTED LOOP，Oracle实际上是把一个两表连接改为三个行源(其中一张表产生两个行源)的连接，并且NESTED LOOP BATCHING可以使用笛卡尔积来处理内循环，这种连接实际上是更为复杂了。因此在统计信息不准，并且表上存在相类似索引或者有共同索引字段索引的时候，很容易选错索引。
Oracle数据库为什么要如此拼命的去提升优化器，提升对数据的处理能力呢?这种情况，让开发商分拆了SQL，取消了表连接，不就不会出问题了呢?实际上这和我今天要谈的问题是有关联的。
前几天有人问我，如果说操作系统是信息化的奠基石，那么数据库算什么?我想了想说，从这个角度讲，数据库是信息化的加速器。
现代的大型数据库系统已经和40多年前刚刚出现的数据库系统完全不是一个概念了，当初的RDBMS主要是作为数据存储和检索的基础设施，能实现高效的存取数据就可以了，而数据处理还是由应用程序去完成。
而现在的大型关系型数据库系统不仅仅是一个数据存储的平台，更是一个数据计算的平台。如果在现代社会里，要求RDBMS回归数据存储与检索的功能，而让更多的数据处理和复杂计算交给程序代码去做，在大多数应用场景下，这实际上是一种技术的倒退，而不是真正的进步。
90年代初，我刚刚参加工作的时候，作为一个软件工程师，接触的数据库系统是十分简单的，当时还不是RDBMS，而是一个记录管理系统(RMS)，我们顶多可以通过索引加速某些检索，不过数据的复杂处理都需要我在C语言的程序里通过自己写算法来进行。这种开发是十分低效，几个月后，我第一次使用大型数据库系统DEC-RDB的时候，发现以前我花半天时间写的处理的数据的程序，改用SQL语句写，几分钟就搞定了，大部分的时候处理效率还比我写的程序高。从那开始我就喜欢上了关系型数据库，这是一个提高开发效率的利器。
从90年代C/S架构逐渐流行开始，位于应用系统后端的大型集中式关系型数据库就已经不是那个当年只是用来存储一些数据的小容器了，而变成了一个数据计算的平台。从那时候起，再把数据库定位为数据存取的IT基础设施就不合适了。以Oracle数据库为例，它不断地把各种数据计算的功能整合在RDBMS中，空间计算、XMLDB等功能不断地充实着Oracle的武器库，甚至在最新的Oracle数据库里，区块链表、深度学习模型等都已经成为了标配的功能。开发人员不需要有太深的人工智能算法和区块链的理论，就可以快速高效的开发相关的应用系统了。
后端强大的计算能力，也让前端开发人员得到了极大的解放，只要能画个界面，写点简单的过程化语言代码的人都可以成为一个合格的程序员了。这个趋势到了B/S架构时代就更为明显了。J2EE框架让应用程序开发的门槛进一步降低，很多中文系的毕业生都加入到了码农的队伍里了。
如果大型关系型数据库没有发展成为一个数据存储、数据处理、数据计算的综合性平台，那么仅仅依靠那些数量有限的长得像黑客一样的人，写着C语言的代码去开发管理信息系统，那么我想我们的信息化进程至少要滞后十年二十年。正是大型关系型数据库让应用开发的门槛降低到了一个十分低的低点，才大大促进了信息化的发展。从这一点上来说，数据库是信息化的加速器，并不夸张。
最近似乎有一种思潮，那就是数据库的功能太强大了，做了太多程序员该做的事情，因此应用的本质需要有所回归，让一些数据处理的工作从数据库中剥离出来，回归到程序中来。这实际上是互联网公司这些年都在做的事情，因为集中式数据库是一个中心单点，是极不容易横向扩展的，对互联网业务的发展是一个极大的制约。因此互联网企业采用分布式架构来打破集中式数据库的瓶颈，将数据分散到海量的分布式的小型数据库中。这种数据架构的变革让以前大型数据库的很多集中式计算的功能都无法完成了，数据库逐渐又退化为数据存取的基础设施了。
互联网企业的成功让很多人都在反思大型数据库是不是捞过界了，是不是真的需要让数据库的功能向其远祖退化。有一阵子我也是这种思潮的粉丝，认为互联网企业的成功可以复制到传统行业中去，从而彻底解决集中式数据库的问题。不过随着这些年在传统行业里摸爬滚打，我发现互联网企业的成功经验并不一定都能够向传统行业去复制，因为业务爆发式的发展，需要处理的数据越来越多，企业管理越来越依赖信息化手段，这导致了信息系统研发的压力越来越大。而我们的研发能力的建设往往要慢得多，因此往往传统行业学习互联网企业的努力变成了东施效颦。
如果所有的传统行业应用开发能力要达到互联网企业的水平，那么具有很高数据复杂处理能力的的程序员就不够用了。信息化的发展是不等人的，不会等我们再花数年的时间去培养一批能够利用互联网架构开发系统的高水平的码农，大量的信息系统的建设还只能采用改良的传统架构。程序员还是需要以写SQL为主去实现复杂的业务逻辑。因此，在目前这个时代里，我们还需要十分强大的数据库来支撑信息化建设，数据库向着更加复杂的数据处理综合平台发展的趋势也会越来越快，哪个数据库产品能够更加高效，更加低代码的实现复杂数据处理，哪个数据库在未来就能占据更大的市场份额。
高效的处理复杂数据对数据库厂商提出了更高的要求，我们的国产数据库不仅仅是要模仿国外商用数据库的形，更要追赶别人在数据处理种类，能力，性能等方面的技术，尽快把自己的产品与竞品的技术差距缩小了。
最后要说的一点，数据库提升数据处理的能力抑或是研发人员方便的使用数据库的超强的数据计算能力并不是说开发人员可以肆无忌惮的写SQL语句，从而让数据库承受巨大的压力。数据库可以高效的处理复杂的数据和业务逻辑，并不等于一切都交给数据库去做。当数据库对某些处理能力不足的时候，还是需要我们的开发人员去优化去规避的。这里只想表达的意思是，限制一条SQL不能超过3张表关联，不能写太复杂的SQL，这只应该是某些技术还不够成熟的特殊阶段的一些限制，随着数据库技术的发展，这些限制肯定是越少越好。
