客戶應用中遇到問題的地方就是國產資料庫的發力點

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

表連線的效能關係到絕大多數管理資訊系統的效能問題，而最常用的表連線方式就是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場景。能夠踏踏實實把使用者最需要的日常問題都解決好了，使用者的應用開發，應用遷移成本都降低了，自然使用你的產品的使用者就會越來越多。