?因?yàn)橐淮笤缬袀€(gè)合作伙伴前來交流，所以昨天的文章實(shí)際上是匆匆發(fā)出來的，并沒有完整的表達(dá)出我對(duì)這個(gè)問題的看法。今天在外面出差，本來和客戶約好上午見面，因?yàn)榕R時(shí)的安排問題，又改到下午了，所以早上有比較充裕的時(shí)間來寫一寫昨天想表達(dá)的另外一層意思。

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

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

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

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

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

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