昨天關(guān)于NESTED LOOP BATCHING的文章，有朋友說這是執(zhí)行計劃選擇錯誤，而不是笛卡爾積的問題。實(shí)際上此類SQL性能問題，都是因?yàn)榻y(tǒng)計數(shù)據(jù)而選錯了執(zhí)行計劃。

昨天談到的問題是因?yàn)镹ESTED LOOP BATCHING的存在，讓NLJ的執(zhí)行計劃選擇變得更為復(fù)雜了，NESTED LOOP BATCHING有三個行源，兩層NESTED LOOP，Oracle實(shí)際上是把一個兩表連接改為三個行源(其中一張表產(chǎn)生兩個行源)的連接，并且NESTED LOOP BATCHING可以使用笛卡爾積來處理內(nèi)循環(huán)，這種連接實(shí)際上是更為復(fù)雜了。因此在統(tǒng)計信息不準(zhǔn)，并且表上存在相類似索引或者有共同索引字段索引的時候，很容易選錯索引。

Oracle數(shù)據(jù)庫為什么要如此拼命的去提升優(yōu)化器，提升對數(shù)據(jù)的處理能力呢?這種情況，讓開發(fā)商分拆了SQL，取消了表連接，不就不會出問題了呢?實(shí)際上這和我今天要談的問題是有關(guān)聯(lián)的。

前幾天有人問我，如果說操作系統(tǒng)是信息化的奠基石，那么數(shù)據(jù)庫算什么?我想了想說，從這個角度講，數(shù)據(jù)庫是信息化的加速器。

現(xiàn)代的大型數(shù)據(jù)庫系統(tǒng)已經(jīng)和40多年前剛剛出現(xiàn)的數(shù)據(jù)庫系統(tǒng)完全不是一個概念了，當(dāng)初的RDBMS主要是作為數(shù)據(jù)存儲和檢索的基礎(chǔ)設(shè)施，能實(shí)現(xiàn)高效的存取數(shù)據(jù)就可以了，而數(shù)據(jù)處理還是由應(yīng)用程序去完成。

而現(xiàn)在的大型關(guān)系型數(shù)據(jù)庫系統(tǒng)不僅僅是一個數(shù)據(jù)存儲的平臺，更是一個數(shù)據(jù)計算的平臺。如果在現(xiàn)代社會里，要求RDBMS回歸數(shù)據(jù)存儲與檢索的功能，而讓更多的數(shù)據(jù)處理和復(fù)雜計算交給程序代碼去做，在大多數(shù)應(yīng)用場景下，這實(shí)際上是一種技術(shù)的倒退，而不是真正的進(jìn)步。

90年代初，我剛剛參加工作的時候，作為一個軟件工程師，接觸的數(shù)據(jù)庫系統(tǒng)是十分簡單的，當(dāng)時還不是RDBMS，而是一個記錄管理系統(tǒng)(RMS)，我們頂多可以通過索引加速某些檢索，不過數(shù)據(jù)的復(fù)雜處理都需要我在C語言的程序里通過自己寫算法來進(jìn)行。這種開發(fā)是十分低效，幾個月后，我第一次使用大型數(shù)據(jù)庫系統(tǒng)DEC-RDB的時候，發(fā)現(xiàn)以前我花半天時間寫的處理的數(shù)據(jù)的程序，改用SQL語句寫，幾分鐘就搞定了，大部分的時候處理效率還比我寫的程序高。從那開始我就喜歡上了關(guān)系型數(shù)據(jù)庫，這是一個提高開發(fā)效率的利器。

從90年代C/S架構(gòu)逐漸流行開始，位于應(yīng)用系統(tǒng)后端的大型集中式關(guān)系型數(shù)據(jù)庫就已經(jīng)不是那個當(dāng)年只是用來存儲一些數(shù)據(jù)的小容器了，而變成了一個數(shù)據(jù)計算的平臺。從那時候起，再把數(shù)據(jù)庫定位為數(shù)據(jù)存取的IT基礎(chǔ)設(shè)施就不合適了。以O(shè)racle數(shù)據(jù)庫為例，它不斷地把各種數(shù)據(jù)計算的功能整合在RDBMS中，空間計算、XMLDB等功能不斷地充實(shí)著Oracle的武器庫，甚至在最新的Oracle數(shù)據(jù)庫里，區(qū)塊鏈表、深度學(xué)習(xí)模型等都已經(jīng)成為了標(biāo)配的功能。開發(fā)人員不需要有太深的人工智能算法和區(qū)塊鏈的理論，就可以快速高效的開發(fā)相關(guān)的應(yīng)用系統(tǒng)了。

后端強(qiáng)大的計算能力，也讓前端開發(fā)人員得到了極大的解放，只要能畫個界面，寫點(diǎn)簡單的過程化語言代碼的人都可以成為一個合格的程序員了。這個趨勢到了B/S架構(gòu)時代就更為明顯了。J2EE框架讓應(yīng)用程序開發(fā)的門檻進(jìn)一步降低，很多中文系的畢業(yè)生都加入到了碼農(nóng)的隊(duì)伍里了。

如果大型關(guān)系型數(shù)據(jù)庫沒有發(fā)展成為一個數(shù)據(jù)存儲、數(shù)據(jù)處理、數(shù)據(jù)計算的綜合性平臺，那么僅僅依靠那些數(shù)量有限的長得像黑客一樣的人，寫著C語言的代碼去開發(fā)管理信息系統(tǒng)，那么我想我們的信息化進(jìn)程至少要滯后十年二十年。正是大型關(guān)系型數(shù)據(jù)庫讓應(yīng)用開發(fā)的門檻降低到了一個十分低的低點(diǎn)，才大大促進(jìn)了信息化的發(fā)展。從這一點(diǎn)上來說，數(shù)據(jù)庫是信息化的加速器，并不夸張。

最近似乎有一種思潮，那就是數(shù)據(jù)庫的功能太強(qiáng)大了，做了太多程序員該做的事情，因此應(yīng)用的本質(zhì)需要有所回歸，讓一些數(shù)據(jù)處理的工作從數(shù)據(jù)庫中剝離出來，回歸到程序中來。這實(shí)際上是互聯(lián)網(wǎng)公司這些年都在做的事情，因?yàn)榧惺綌?shù)據(jù)庫是一個中心單點(diǎn)，是極不容易橫向擴(kuò)展的，對互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展是一個極大的制約。因此互聯(lián)網(wǎng)企業(yè)采用分布式架構(gòu)來打破集中式數(shù)據(jù)庫的瓶頸，將數(shù)據(jù)分散到海量的分布式的小型數(shù)據(jù)庫中。這種數(shù)據(jù)架構(gòu)的變革讓以前大型數(shù)據(jù)庫的很多集中式計算的功能都無法完成了，數(shù)據(jù)庫逐漸又退化為數(shù)據(jù)存取的基礎(chǔ)設(shè)施了。

互聯(lián)網(wǎng)企業(yè)的成功讓很多人都在反思大型數(shù)據(jù)庫是不是撈過界了，是不是真的需要讓數(shù)據(jù)庫的功能向其遠(yuǎn)祖退化。有一陣子我也是這種思潮的粉絲，認(rèn)為互聯(lián)網(wǎng)企業(yè)的成功可以復(fù)制到傳統(tǒng)行業(yè)中去，從而徹底解決集中式數(shù)據(jù)庫的問題。不過隨著這些年在傳統(tǒng)行業(yè)里摸爬滾打，我發(fā)現(xiàn)互聯(lián)網(wǎng)企業(yè)的成功經(jīng)驗(yàn)并不一定都能夠向傳統(tǒng)行業(yè)去復(fù)制，因?yàn)闃I(yè)務(wù)爆發(fā)式的發(fā)展，需要處理的數(shù)據(jù)越來越多，企業(yè)管理越來越依賴信息化手段，這導(dǎo)致了信息系統(tǒng)研發(fā)的壓力越來越大。而我們的研發(fā)能力的建設(shè)往往要慢得多，因此往往傳統(tǒng)行業(yè)學(xué)習(xí)互聯(lián)網(wǎng)企業(yè)的努力變成了東施效顰。

如果所有的傳統(tǒng)行業(yè)應(yīng)用開發(fā)能力要達(dá)到互聯(lián)網(wǎng)企業(yè)的水平，那么具有很高數(shù)據(jù)復(fù)雜處理能力的的程序員就不夠用了。信息化的發(fā)展是不等人的，不會等我們再花數(shù)年的時間去培養(yǎng)一批能夠利用互聯(lián)網(wǎng)架構(gòu)開發(fā)系統(tǒng)的高水平的碼農(nóng)，大量的信息系統(tǒng)的建設(shè)還只能采用改良的傳統(tǒng)架構(gòu)。程序員還是需要以寫SQL為主去實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)邏輯。因此，在目前這個時代里，我們還需要十分強(qiáng)大的數(shù)據(jù)庫來支撐信息化建設(shè)，數(shù)據(jù)庫向著更加復(fù)雜的數(shù)據(jù)處理綜合平臺發(fā)展的趨勢也會越來越快，哪個數(shù)據(jù)庫產(chǎn)品能夠更加高效，更加低代碼的實(shí)現(xiàn)復(fù)雜數(shù)據(jù)處理，哪個數(shù)據(jù)庫在未來就能占據(jù)更大的市場份額。

高效的處理復(fù)雜數(shù)據(jù)對數(shù)據(jù)庫廠商提出了更高的要求，我們的國產(chǎn)數(shù)據(jù)庫不僅僅是要模仿國外商用數(shù)據(jù)庫的形，更要追趕別人在數(shù)據(jù)處理種類，能力，性能等方面的技術(shù)，盡快把自己的產(chǎn)品與競品的技術(shù)差距縮小了。

最后要說的一點(diǎn)，數(shù)據(jù)庫提升數(shù)據(jù)處理的能力抑或是研發(fā)人員方便的使用數(shù)據(jù)庫的超強(qiáng)的數(shù)據(jù)計算能力并不是說開發(fā)人員可以肆無忌憚的寫SQL語句，從而讓數(shù)據(jù)庫承受巨大的壓力。數(shù)據(jù)庫可以高效的處理復(fù)雜的數(shù)據(jù)和業(yè)務(wù)邏輯，并不等于一切都交給數(shù)據(jù)庫去做。當(dāng)數(shù)據(jù)庫對某些處理能力不足的時候，還是需要我們的開發(fā)人員去優(yōu)化去規(guī)避的。這里只想表達(dá)的意思是，限制一條SQL不能超過3張表關(guān)聯(lián)，不能寫太復(fù)雜的SQL，這只應(yīng)該是某些技術(shù)還不夠成熟的特殊階段的一些限制，隨著數(shù)據(jù)庫技術(shù)的發(fā)展，這些限制肯定是越少越好。