?前幾天一個(gè)做數(shù)據(jù)庫(kù)產(chǎn)品的朋友和我聊起在國(guó)產(chǎn)數(shù)據(jù)庫(kù)上的彎道超車問(wèn)題，他覺(jué)得對(duì)于通用關(guān)系型數(shù)據(jù)庫(kù)，Oracle已經(jīng)領(lǐng)先太多了，如果不彎道超車，國(guó)產(chǎn)數(shù)據(jù)庫(kù)永遠(yuǎn)沒(méi)有機(jī)會(huì)趕上Oracle。彎道超車一直被很多朋友看作是超越的捷徑，不過(guò)我認(rèn)為彎道超車一定是以實(shí)力作為后盾才能夠完成的。要想彎道超車，后車的引擎必須高于前車，至少是二者相當(dāng)，沒(méi)有實(shí)力做保障，彎道技術(shù)再好，也是很難完成超車的。

在通用關(guān)系型數(shù)據(jù)庫(kù)領(lǐng)域，想要對(duì)Oracle實(shí)現(xiàn)彎道超車，大家都會(huì)選擇CBO優(yōu)化器。AI4DB是被大家寄予厚望的。通過(guò)AI算法的輔助來(lái)糾正執(zhí)行計(jì)劃中的錯(cuò)誤，或者幫助某條SQL選擇一個(gè)更好的執(zhí)行計(jì)劃。其主要方法是基于歷史數(shù)據(jù)的分析，通過(guò)一定的參數(shù)（比如表分析數(shù)據(jù)、歷史執(zhí)行計(jì)劃的效率等），通過(guò)算法計(jì)算執(zhí)行計(jì)劃的成本，在重大決策中輔助CBO的規(guī)則引擎，比如當(dāng)HASH JOIN和NESTED LOOP經(jīng)常會(huì)選錯(cuò)的時(shí)候，通過(guò)AI算法輔助，讓CBO選擇的執(zhí)行計(jì)劃更為準(zhǔn)確。

實(shí)際上Oracle這些年也一直CBO上發(fā)力，動(dòng)態(tài)CURSOR是Oracle用于解決這個(gè)問(wèn)題的方法，當(dāng)SQL在執(zhí)行過(guò)程中發(fā)現(xiàn)NESTED LOOP成本過(guò)高的時(shí)候，自動(dòng)將目前的執(zhí)行暫停，更換為HASH JOIN，從而避免某些SQL出現(xiàn)嚴(yán)重的性能問(wèn)題。只不過(guò)Oracle目前的算法還不夠完善，因此動(dòng)態(tài)CURSOR有時(shí)候還會(huì)出錯(cuò)。

Oracle的CBO優(yōu)化器是基于數(shù)據(jù)模型的優(yōu)選算法的，其主要方法是通過(guò)各種統(tǒng)計(jì)數(shù)據(jù)，對(duì)某個(gè)SQL的不同算子計(jì)算成本，最后將一條SQL的各種執(zhí)行方式的成本都算完后，選擇其中成本最低的執(zhí)行計(jì)劃去執(zhí)行。這種方法也是目前絕大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)分析執(zhí)行計(jì)劃的基礎(chǔ)算法。到目前的版本為止，Oracle并沒(méi)有選擇通過(guò)AI算法來(lái)獲得執(zhí)行計(jì)劃，而是繼續(xù)沿用其傳統(tǒng)的算法。不過(guò)隨著Oracle的數(shù)十年的發(fā)展，其CBO優(yōu)化器的核心算法基礎(chǔ)上，已經(jīng)積累了大量的補(bǔ)丁，這些補(bǔ)丁都是對(duì)核心主算法的糾正，在Oracle內(nèi)部被稱為FIX。每個(gè)FIX實(shí)際上就是一個(gè)特殊場(chǎng)景下SQL選擇執(zhí)行計(jì)劃中的修正模型，都是在實(shí)戰(zhàn)中遇到問(wèn)題后，標(biāo)準(zhǔn)CBO算法無(wú)法解決問(wèn)題時(shí)的一種特殊處理，也可以稱為經(jīng)驗(yàn)?zāi)Ｐ汀４送猓琌racle還將其中的一些特別重要的修正進(jìn)行了特殊的處理，設(shè)置了一些隱含參數(shù)加以控制。這些修正往往不是CBO優(yōu)化器的不足，而是在不同的應(yīng)用場(chǎng)景中，特殊的用戶數(shù)據(jù)與用戶硬件環(huán)境可能導(dǎo)致CBO優(yōu)化器產(chǎn)生錯(cuò)誤的選擇，通過(guò)這些參數(shù)可以加以調(diào)整。其中最為著名的莫過(guò)于optimizer_index_cost_adj，這個(gè)參數(shù)可以調(diào)整CBO優(yōu)化器在計(jì)算索引掃描時(shí)的成本，在二十年前的Oracle 8i/9i時(shí)代，我們經(jīng)常通過(guò)調(diào)整這個(gè)參數(shù)來(lái)避免不必要的對(duì)全表掃描的錯(cuò)誤選擇，讓數(shù)據(jù)庫(kù)更傾向于使用索引掃描。

在Oracle 11.2.0.4中，CBO優(yōu)化器的可調(diào)整參數(shù)有329個(gè)，F(xiàn)IX有846個(gè)。到了19.15.0.0版本，CBO優(yōu)化器可調(diào)整參數(shù)的數(shù)量高達(dá)612個(gè)，F(xiàn)IX的數(shù)量達(dá)到了1369個(gè)。實(shí)際上每個(gè)FIX后面都有無(wú)數(shù)個(gè)用戶的痛苦經(jīng)歷，是Oracle數(shù)據(jù)庫(kù)的CBO優(yōu)化器在用戶環(huán)境中遇到了問(wèn)題后的修正。

Oracle數(shù)據(jù)庫(kù)的優(yōu)化器是十分優(yōu)秀的，這一點(diǎn)大家都是公認(rèn)的，但是其優(yōu)秀的優(yōu)化器依然無(wú)法解決所有的用戶的問(wèn)題，依然需要不斷的通過(guò)添加參數(shù)來(lái)做更精細(xì)的控制，甚至加入某些特殊的修正來(lái)解決問(wèn)題。

目前我們國(guó)產(chǎn)數(shù)據(jù)庫(kù)的優(yōu)化器恐怕還在重點(diǎn)完善CBO優(yōu)化器的核心算法，還沒(méi)有遇到過(guò)如此多的實(shí)戰(zhàn)案例，發(fā)現(xiàn)那么多主邏輯可能存在的問(wèn)題。這些參數(shù)與FIX必須是在大量的實(shí)戰(zhàn)中獲得的，因此有些國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠家想另辟蹊徑了。通過(guò)AI4DB是不是可以繞開(kāi)這個(gè)問(wèn)題，實(shí)現(xiàn)在CBO上的彎道超車呢？恐怕有此想法的朋友要失望了，CBO優(yōu)化器是基于統(tǒng)計(jì)數(shù)據(jù)與算法規(guī)則的，歷史的SQL執(zhí)行情況可以提供參考，但是無(wú)法作為下一次解析SQL時(shí)的可靠依據(jù)。因?yàn)閿?shù)據(jù)在不斷的變化，參數(shù)也在變化，而CBO優(yōu)化器的每次解析，都決定了SQL語(yǔ)句是否能夠合理的執(zhí)行。一次錯(cuò)誤的解析很可能引發(fā)一場(chǎng)災(zāi)難。因此AI算法在這個(gè)場(chǎng)景中可以起到輔助發(fā)現(xiàn)SQL問(wèn)題的作用，但是無(wú)法替代規(guī)則來(lái)生成執(zhí)行計(jì)劃。我們的CBO優(yōu)化器也只能在實(shí)戰(zhàn)中不斷的經(jīng)受挑戰(zhàn)，不斷的經(jīng)歷痛苦的折騰，才能變得越來(lái)越強(qiáng)大。當(dāng)我們的優(yōu)化器的FIX和可調(diào)整參數(shù)能夠達(dá)到Oracle的時(shí)候，才真正算是成熟了。CBO優(yōu)化器成長(zhǎng)的最佳途徑是在實(shí)戰(zhàn)中不斷完善，而不是憑著我們的研發(fā)人員的想象力，在家里閉門造車。

先不要空談彎道超車，扎扎實(shí)實(shí)的在用戶廠家中去修煉，把優(yōu)化器一點(diǎn)點(diǎn)做好吧，實(shí)際上在現(xiàn)階段，能夠先遠(yuǎn)遠(yuǎn)的跟上最先進(jìn)的數(shù)據(jù)庫(kù)產(chǎn)品，已經(jīng)是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的成功了。