[[442501]]

傳統(tǒng)的Oracle DBA都會(huì)把SQL解析問題看的很嚴(yán)重，這實(shí)際上是來自于早年的DBA對共享池問題的恐懼。實(shí)際上，我剛剛開始接觸數(shù)據(jù)庫的時(shí)候，SQL解析根本不是一個(gè)什么技術(shù)問題，因?yàn)槟菚r(shí)候的服務(wù)器的性能有限，頂多兩顆CPU，幾十M的物理內(nèi)存，雖然連接了幾十臺(tái)上百臺(tái)終端，實(shí)際上大多數(shù)時(shí)候都在處理前端顯示等緩慢的外設(shè)操作。真正訪問數(shù)據(jù)庫的并發(fā)量并不大，因此那時(shí)候的數(shù)據(jù)庫問題主要還是DB CACHE的命中率問題，只要保證DB CACHE命中率高于80%，大多數(shù)SQL都能跑的還可以。不過那時(shí)候的SQL也都比較簡單，碼農(nóng)的素質(zhì)也比較高，自己能用算法搞定的事情一般不會(huì)交給數(shù)據(jù)庫去做。

不過后來隨著C/S架構(gòu)的發(fā)展，前端的并發(fā)量越來越大了，小型機(jī)服務(wù)器的處理能力也大了起來，95年，DEC公司推出了VLM和VLDB的概念，VLM就是VERY LARGE MEMORY，VLDB就是VERY LARGE DATABASE，這是因?yàn)?4位的芯片誕生了，這個(gè)芯片就是ALPHA 21064,這個(gè)現(xiàn)在已經(jīng)賣身成為申威的芯片是世界上第一顆商用的64位芯片。由于內(nèi)存一下子進(jìn)入了GB級別，數(shù)據(jù)庫的規(guī)模也從MB級別變成GB級別的了，C/S架構(gòu)又讓前端的并發(fā)量有了質(zhì)的提升，因此和shared pool相關(guān)的問題逐漸多了起來。而雖然已經(jīng)進(jìn)入了VLM時(shí)代，不過那時(shí)候的HP/IBM們還只有32位的芯片，哪怕是64位的服務(wù)器上，要配備好幾個(gè)GB的物理內(nèi)存依然是十分昂貴的。因此那時(shí)候的數(shù)據(jù)庫SHARED POOL的配置都是十分可憐的，200M以上的SHARED POOL就算是比較豪華的了，正是因?yàn)檫@個(gè)原因，共享池帶來的并發(fā)爭用經(jīng)常會(huì)成為DBA的噩夢。

哪怕后來內(nèi)存稍微寬松一些了，可以配置較大的共享池了，那時(shí)候服務(wù)器的CPU還是過于昂貴，因此如何讓CPU把更多的資源用于SQL執(zhí)行，Oracle在CURSOR共享上下足了大功夫，盡可能地讓一個(gè)CURSOR編譯后的資源能夠被更多的會(huì)話和執(zhí)行共享。這個(gè)工作讓共享池變得十分復(fù)雜，也變成了一個(gè)十分容易出問題的組件。90年代末00年代初的DBA都在共享池問題上吃過大苦頭。因此大量的文檔資料都對共享池問題，硬解析問題做了大量的分析。而從DBA這個(gè)師傅帶徒弟的方式傳承的職業(yè)上，這種恐懼被一代代的傳了下來。

至少在5年前，還經(jīng)常有DBA和我探討數(shù)據(jù)庫性能問題的時(shí)候，都會(huì)把硬解析數(shù)量放在比較重要的位置上去考慮。我要費(fèi)挺大的勁兒去解釋，硬解析雖然多了點(diǎn)，但是你的系統(tǒng)問題主要不是硬解析引起的，因?yàn)楣蚕沓氐臓幱貌⒉粐?yán)重。

雖然說，Oracle 10g推出了SGA 動(dòng)態(tài)調(diào)整技術(shù)之后，共享池引起的大問題逐漸少了很多，而隨著服務(wù)器技術(shù)的發(fā)展，特別是去IOE時(shí)代開始的X86替代小型機(jī)之后，內(nèi)存，CPU變得十分便宜了。因此我們的服務(wù)器都可以配備了超豪華的CPU/內(nèi)存/IO資源了，還是有大量的DBA依然受到那時(shí)候的影響，對SQL解析十分恐懼。這個(gè)恐懼甚至帶到了開源數(shù)據(jù)庫和國產(chǎn)數(shù)據(jù)庫上。

實(shí)際上，在大多數(shù)開源和國產(chǎn)數(shù)據(jù)庫上，并不存在全局共享的CURSOR，一般來說，CURSOR共享是會(huì)話級的。這種設(shè)計(jì)讓Oracle 復(fù)雜的共享池結(jié)構(gòu)對于開源數(shù)據(jù)庫來說變得簡單的多了，它們只需要共享字典緩存就可以了，SQL執(zhí)行的CURSOR結(jié)構(gòu)在會(huì)話內(nèi)共享就可以了。這種基于會(huì)話的CURSOR共享，對DBA來說絕對是一個(gè)福音，因?yàn)檫@種結(jié)構(gòu)十分簡單，不容易出現(xiàn)閂鎖的問題。

當(dāng)數(shù)據(jù)庫在高并發(fā)SQL執(zhí)行的時(shí)候，只需要增加一點(diǎn)點(diǎn)SQL解析的CPU和內(nèi)存開銷就可以了。而這兩種資源在現(xiàn)在的服務(wù)器上，已經(jīng)是十分便宜了。因此在開源和國產(chǎn)數(shù)據(jù)庫上，我們很少聽說SQL解析引起的性能問題。除非是CPU或者內(nèi)存資源嚴(yán)重不足的系統(tǒng)中，這類問題恐怕都不是問題。

采用會(huì)話內(nèi)共享CURSOR是硬件發(fā)展的必然選擇，新數(shù)據(jù)庫也沒必要再去研發(fā)Oracle那種復(fù)雜的共享池了，這對于數(shù)據(jù)庫產(chǎn)業(yè)來說是件好事，因?yàn)檎嬲軌蛲孓D(zhuǎn)復(fù)雜的共享池的，目前為止也只有Oracle一家。前陣子有個(gè)數(shù)據(jù)庫研發(fā)人員和我探討，他想在他們的自研數(shù)據(jù)庫里引入類似Oracle的共享池，從而減少SQL解析的開銷。我建議他不要這么做，一條比較爛的SQL消耗的CPU內(nèi)存資源，就可以把他們花數(shù)千萬研發(fā)出來的共享池節(jié)約的那點(diǎn)可憐的資源全部消耗掉，甚至成十倍百倍的消耗掉，有那個(gè)錢還不如投入到改善CBO優(yōu)化器上去。

幸運(yùn)的是，現(xiàn)在的DBA不需要像我們那樣經(jīng)常面對痛苦的共享池問題，那個(gè)問題像幽靈一樣，沒有任何跡象，說啥時(shí)候爆發(fā)就啥時(shí)候爆發(fā)。那時(shí)候，半夜被電話鈴聲吵醒的時(shí)候，害怕共享池出問題的恐懼甚至甚過數(shù)據(jù)庫宕機(jī)。