對國產資料庫廠商提幾個關於SQL引擎的小需求

國產資料庫迎來了一個高速發展的好時期，大量的企業使用者正在將他們的資料庫系統遷移到開源和國產資料庫平臺上。不過我們的國產資料庫廠商在大量收割使用者和“數鈔票”的時候，廣大的使用者也在期盼著國產資料庫變得更好用。SQL引擎是資料庫最為核心的元件之一，因此大量國產資料庫廠商在內卷競爭的時候，也需要能夠做出一些讓廣大使用者滿意的功能來。

我們團隊常年從事系統最佳化和資料庫運維工具開發，這些年也接觸了大量的使用者，遇到過大量的資料庫的坑，其中大部分是和SQL引擎有關的。因此今天我也代表廣大的使用者，給國產資料庫提出一些關於SQL引擎方面的功能需求。希望在新一個版本的國產資料庫中，能夠看到這些功能被逐步實現了。

如果最希望國產資料庫SQL引擎具有的功能就是全功能的HASH JOIN，大家都知道HASH JOIN是解決大資料量的表關聯問題的最有效的連線方式。Oracle的HASH JOIN很強大，大量複雜的連線條件，都可以透過HASH JOIN來擺平。雖然現在很多開源、國產資料庫都支援HASH JOIN，不過對HASH JOIN的支援上依然存在很多的盲點。如果遇到某些情況下，正好HASH JOIN無法使用，那麼這條SQL就只剩下改寫一條路了，這對於開發人員和DBA來說就是災難。

第二個需求是SQL指紋和執行計劃指紋。SQL指紋和SQL ID不完全是一回事，SQL ID只能指向一條唯一的SQL語句，而SQL指紋可以將一組存在略微差異的SQL語句歸類為一種SQL。比如我們有一條SQL，除了某些大小寫不同，其他是相同的，或者只有某個變數不同，其他是相同的，那麼這些不同的SQL應該是同一條SQL，雖然這些SQL的SQL ID可能不同，不過這些SQL具有相同的指紋資訊。透過這些指紋可以找到這類相同的SQL，進行統一的分析。執行計劃指紋是指完全相同的執行計劃，有可能不同SQL ID的SQL會使用相同的執行計劃，在SQL中會有一個執行計劃指紋的標識，指向這個執行計劃。透過“執行計劃指紋”，我們可以減少儲存在記憶體中的執行計劃數量，不管是否實現了全域性執行計劃，都可以將執行計劃儲存在一個共享記憶體區域中，供監控分析人員使用。類似的SQL指紋與執行計劃指紋的功能實際上在Oracle資料庫中大多數已經實現了，有興趣的朋友可以去研究一下。

第三個需求是HINT，最佳化器的提升是相當困難的，需要大量的資金投入和時間的沉澱才可以做得越來越好，絕對無法依靠某幾個聰明的高手就可以完成。如果遇到了CBO最佳化器真的無法做出正確判斷，非要使用錯誤的執行計劃的時候，開發人員還是可以透過HINT來強制矯正執行計劃的。目前也有一些國產資料庫和開源資料庫支援hint了。不過在實現方法上，很多國產和開源資料庫是透過外掛方式，利用資料庫程式碼中的鉤子來實現的，另外HINT支援的操作也還不是很完整。透過鉤子的外掛實現方式還是沒有原生態的核心支援效率更高，在核心中直接支援豐富的HINT絕對是提升國產資料庫SQL解析效率的必然途徑。在HINT支援的操作方面，HINT不僅僅可以強制指定某種執行方案，還可以實現叢集計算環境中的強讀寫分離、弱讀寫分離等功能。比如設定叢集計算環境中MASTER選擇的策略，以及指明某操作可以放置於只讀節點，甚至指明某個操作是弱一致性操作，執行資料延時的最大限制等。這些HINT往往需要叢集計算環境被納入到資料庫的核心中，而不僅僅是外掛的。

第四個需求是OUTLINES的原生態支援，當我們無法直接修改SQL，新增HINT來強制指定一個比較最佳化的執行計劃的時候，就只能依靠OUTLINES了。傳統的OUTLINES只能針對某個SQL ID，如果存在一些沒有使用繫結變數的情況，就沒辦法透過SQL ID來指定OUTLINES。而往往一個系統中，這些SQL才是最常用的，也是最重要的。在OUTLINES的實現上，如果可以透過SQL指紋來設定，那麼OUTLINES將會有更廣泛的用途。

第五個需求是長時間執行的SQL執行進度視覺化，提供一個類似於Oracle V$SESSION_LONGOPS的外部介面檢視。不過希望能夠比Oracle提供更多一些的資訊。比如當前這個操作來自於哪個執行計劃(執行計劃指紋)，以及這個操作處於執行計劃的第幾個步驟。當然這種SQL執行進度視覺化僅僅顯示長時間執行的操作，只有當執行計劃中的某個運算元執行成本超過一定閾值的時候，才需要輸出到介面中，否則這種輸出會影響SQL引擎的效率。這部分功能實現只要到某個運算元級別就可以了，不需要做SQL級別的，SQL引擎還是效能為先，視覺化是次要的。

其實SQL引擎中的最佳化器是改進難度最大的部件，需要有大量的應用案例來促進其最佳化和改進。而且有些最佳化器的功能最佳化難度極大，要做出一個優秀的CBO最佳化器其實不是一朝一夕就能夠完成的。不過在最佳化器達到完美之前，必須是夠用的。也就是能夠儘可能讓我們的開發人員不要總是面臨SQL不改寫就無法正常執行的困境。使用者的應用場景十分複雜，因此作為國產資料庫的開發者，集中力量去解決必須解決的問題，剩下的問題透過HINT，OUTLINES這樣似乎不是太智慧化的手段來彌補最佳化器的能力不足，也是是必須的。不管怎麼說，能夠解決使用者問題的資料庫就是好資料庫。