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

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

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

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

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

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

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