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

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

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

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

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

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

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

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