?因為一大早有個合作伙伴前來交流，所以昨天的文章實際上是匆匆發(fā)出來的，并沒有完整的表達出我對這個問題的看法。今天在外面出差，本來和客戶約好上午見面，因為臨時的安排問題，又改到下午了，所以早上有比較充裕的時間來寫一寫昨天想表達的另外一層意思。

表連接的性能關(guān)系到絕大多數(shù)管理信息系統(tǒng)的性能問題，而最常用的表連接方式就是NESTED LOOP和HASH JOIN。當HASH JOIN還不成熟的時候，NESTED LOOP是主打，不過對于一些左表返回數(shù)據(jù)較多或者說找不到一張返回數(shù)據(jù)量較少（比如小于幾百）的左表的情況下，SQL的性能是很差的。HASH JOIN讓一些大查詢的性能得到了有效的優(yōu)化。不過HASH JOIN也不是任何時候都有效的，如果原本使用NESTED LOOP的連接被錯誤的選擇為HASH JOIN，會帶來巨大的不必要的掃描開銷，也會影響SQL的執(zhí)行時間。因此選擇適當?shù)谋磉B接方式對于SQL性能來說十分關(guān)鍵。

昨天在我的測試中存在問題的執(zhí)行計劃，實際上都是企業(yè)的信息系統(tǒng)中很常見的SQL產(chǎn)生的，這些SQL在Oracle中表現(xiàn)都是很好的，而當使用某些開源數(shù)據(jù)庫或者國產(chǎn)數(shù)據(jù)庫時才會出現(xiàn)問題，這也反映出我們的國產(chǎn)數(shù)據(jù)庫在優(yōu)化器上與Oracle的差距。優(yōu)化常見表連接的執(zhí)行計劃的能力，實際上應(yīng)該作為國產(chǎn)數(shù)據(jù)庫十分重要的一項工作來做。

SQL解析過程中都會有SQL REWRITE這個階段，實際上我們遇到的很多SQL的執(zhí)行計劃有問題，都是在這個階段沒能改寫出更優(yōu)的SQL來，所以后續(xù)的執(zhí)行計劃生成就會陷入到優(yōu)化器的缺陷中了。優(yōu)化器的改進是個十分艱苦的過程，其難度巨大，PG數(shù)據(jù)庫這些年雖然版本迭代很快，但是優(yōu)化器中的幾個頑疾一直沒有解決掉（昨天我舉的例子中的執(zhí)行計劃存在問題的地方，都是PG優(yōu)化器由來已久的頑疾），這也充分說明了優(yōu)化器核心提升的難度。

不過SQL REWRITE這個階段與優(yōu)化器的核心之間相對獨立（當然其中關(guān)聯(lián)也十分緊密），因此優(yōu)化SQL REWRITE階段的能力可以作為數(shù)據(jù)庫廠商優(yōu)先發(fā)力的地方，能夠把一個優(yōu)化器較難處理的SQL改寫出一個比較容易處理的SQL，那么某些老大難的問題就不需要動優(yōu)化器的核心，也能夠解決問題了。

一年期我寫過一篇文章《從兩個小例子看我們的差距》，其中一個是我們以前討論過的一個ORACLE CBO優(yōu)化器的例子。在一份100053 trace里，我看到了一個十分奇怪的現(xiàn)象，SQL語句被莫名其妙的做了一次謂詞內(nèi)推（FPD）的轉(zhuǎn)換，在SQL上莫名其妙的增加了一個基于函數(shù)索引的謂詞斷語。剛開始的時候，我認為這種SQL REWRITE后，甚至語義都變了，SQL的執(zhí)行結(jié)果都有可能不對了，Oracle CBO為什么要做這樣的FPD呢。后來經(jīng)過分析發(fā)現(xiàn)SQL有個WHERE  ADATE=’20210102 122103’ 這樣的條件，不過ADATE上并無索引，不過存在一個substr(ADATE,1,8)索引。按理說這個索引不會被使用，不過這個場景下，使用函數(shù)索引能夠有效地提高SQL的效率。而在Oracle的核心優(yōu)化器中增加這方面的能力將會是一個大改動，于是Oracle巧妙的添加了一條FPD規(guī)則，對此類SQL通過規(guī)則進行一次簡單的改寫，優(yōu)化器對于處理此類Sql的性能就大大提高了。

最近這一年里，做了大量的數(shù)據(jù)庫國產(chǎn)化替代相關(guān)研究與測試工作，我發(fā)現(xiàn)現(xiàn)在絕大多數(shù)國產(chǎn)數(shù)據(jù)庫都在高唱秒殺一切的性能，優(yōu)秀的TPC-C/TPC-H指標，不過我們的用戶的實際體驗是應(yīng)用從Oracle遷移下來以后大量的SQL執(zhí)行性能下降數(shù)十倍甚至數(shù)百倍。基于這些應(yīng)用體驗，我覺得我們的國產(chǎn)數(shù)據(jù)庫廠商真的需要在這些“小地方”多下點功夫，能夠讓用戶用得更爽。因為我們用戶的應(yīng)用場景中，超過99%的場景是普通的管理信息系統(tǒng)，而不是超高并發(fā)，超高交易量的TPMC場景。能夠踏踏實實把用戶最需要的日常問題都解決好了，用戶的應(yīng)用開發(fā)，應(yīng)用遷移成本都降低了，自然使用你的產(chǎn)品的用戶就會越來越多。