國(guó)產(chǎn)數(shù)據(jù)庫(kù)迎來(lái)了一個(gè)高速發(fā)展的好時(shí)期，大量的企業(yè)用戶正在將他們的數(shù)據(jù)庫(kù)系統(tǒng)遷移到開(kāi)源和國(guó)產(chǎn)數(shù)據(jù)庫(kù)平臺(tái)上。不過(guò)我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商在大量收割用戶和“數(shù)鈔票”的時(shí)候，廣大的用戶也在期盼著國(guó)產(chǎn)數(shù)據(jù)庫(kù)變得更好用。SQL引擎是數(shù)據(jù)庫(kù)最為核心的組件之一，因此大量國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商在內(nèi)卷競(jìng)爭(zhēng)的時(shí)候，也需要能夠做出一些讓廣大用戶滿意的功能來(lái)。

我們團(tuán)隊(duì)常年從事系統(tǒng)優(yōu)化和數(shù)據(jù)庫(kù)運(yùn)維工具開(kāi)發(fā)，這些年也接觸了大量的用戶，遇到過(guò)大量的數(shù)據(jù)庫(kù)的坑，其中大部分是和SQL引擎有關(guān)的。因此今天我也代表廣大的用戶，給國(guó)產(chǎn)數(shù)據(jù)庫(kù)提出一些關(guān)于SQL引擎方面的功能需求。希望在新一個(gè)版本的國(guó)產(chǎn)數(shù)據(jù)庫(kù)中，能夠看到這些功能被逐步實(shí)現(xiàn)了。

如果最希望國(guó)產(chǎn)數(shù)據(jù)庫(kù)SQL引擎具有的功能就是全功能的HASH JOIN，大家都知道HASH JOIN是解決大數(shù)據(jù)量的表關(guān)聯(lián)問(wèn)題的最有效的連接方式。Oracle的HASH JOIN很強(qiáng)大，大量復(fù)雜的連接條件，都可以通過(guò)HASH JOIN來(lái)擺平。雖然現(xiàn)在很多開(kāi)源、國(guó)產(chǎn)數(shù)據(jù)庫(kù)都支持HASH JOIN，不過(guò)對(duì)HASH JOIN的支持上依然存在很多的盲點(diǎn)。如果遇到某些情況下，正好HASH JOIN無(wú)法使用，那么這條SQL就只剩下改寫(xiě)一條路了，這對(duì)于開(kāi)發(fā)人員和DBA來(lái)說(shuō)就是災(zāi)難。

第二個(gè)需求是SQL指紋和執(zhí)行計(jì)劃指紋。SQL指紋和SQL ID不完全是一回事，SQL ID只能指向一條唯一的SQL語(yǔ)句，而SQL指紋可以將一組存在略微差異的SQL語(yǔ)句歸類(lèi)為一種SQL。比如我們有一條SQL，除了某些大小寫(xiě)不同，其他是相同的，或者只有某個(gè)變量不同，其他是相同的，那么這些不同的SQL應(yīng)該是同一條SQL，雖然這些SQL的SQL ID可能不同，不過(guò)這些SQL具有相同的指紋信息。通過(guò)這些指紋可以找到這類(lèi)相同的SQL，進(jìn)行統(tǒng)一的分析。執(zhí)行計(jì)劃指紋是指完全相同的執(zhí)行計(jì)劃，有可能不同SQL ID的SQL會(huì)使用相同的執(zhí)行計(jì)劃，在SQL中會(huì)有一個(gè)執(zhí)行計(jì)劃指紋的標(biāo)識(shí)，指向這個(gè)執(zhí)行計(jì)劃。通過(guò)“執(zhí)行計(jì)劃指紋”，我們可以減少保存在內(nèi)存中的執(zhí)行計(jì)劃數(shù)量，不管是否實(shí)現(xiàn)了全局執(zhí)行計(jì)劃，都可以將執(zhí)行計(jì)劃存儲(chǔ)在一個(gè)共享內(nèi)存區(qū)域中，供監(jiān)控分析人員使用。類(lèi)似的SQL指紋與執(zhí)行計(jì)劃指紋的功能實(shí)際上在Oracle數(shù)據(jù)庫(kù)中大多數(shù)已經(jīng)實(shí)現(xiàn)了，有興趣的朋友可以去研究一下。

第三個(gè)需求是HINT，優(yōu)化器的提升是相當(dāng)困難的，需要大量的資金投入和時(shí)間的沉淀才可以做得越來(lái)越好，絕對(duì)無(wú)法依靠某幾個(gè)聰明的高手就可以完成。如果遇到了CBO優(yōu)化器真的無(wú)法做出正確判斷，非要使用錯(cuò)誤的執(zhí)行計(jì)劃的時(shí)候，開(kāi)發(fā)人員還是可以通過(guò)HINT來(lái)強(qiáng)制矯正執(zhí)行計(jì)劃的。目前也有一些國(guó)產(chǎn)數(shù)據(jù)庫(kù)和開(kāi)源數(shù)據(jù)庫(kù)支持hint了。不過(guò)在實(shí)現(xiàn)方法上，很多國(guó)產(chǎn)和開(kāi)源數(shù)據(jù)庫(kù)是通過(guò)外掛方式，利用數(shù)據(jù)庫(kù)代碼中的鉤子來(lái)實(shí)現(xiàn)的，另外HINT支持的操作也還不是很完整。通過(guò)鉤子的插件實(shí)現(xiàn)方式還是沒(méi)有原生態(tài)的內(nèi)核支持效率更高，在內(nèi)核中直接支持豐富的HINT絕對(duì)是提升國(guó)產(chǎn)數(shù)據(jù)庫(kù)SQL解析效率的必然途徑。在HINT支持的操作方面，HINT不僅僅可以強(qiáng)制指定某種執(zhí)行方案，還可以實(shí)現(xiàn)集群計(jì)算環(huán)境中的強(qiáng)讀寫(xiě)分離、弱讀寫(xiě)分離等功能。比如設(shè)定集群計(jì)算環(huán)境中MASTER選擇的策略，以及指明某操作可以放置于只讀節(jié)點(diǎn)，甚至指明某個(gè)操作是弱一致性操作，運(yùn)行數(shù)據(jù)延時(shí)的最大限制等。這些HINT往往需要集群計(jì)算環(huán)境被納入到數(shù)據(jù)庫(kù)的內(nèi)核中，而不僅僅是外掛的。

第四個(gè)需求是OUTLINES的原生態(tài)支持，當(dāng)我們無(wú)法直接修改SQL，添加HINT來(lái)強(qiáng)制指定一個(gè)比較優(yōu)化的執(zhí)行計(jì)劃的時(shí)候，就只能依靠OUTLINES了。傳統(tǒng)的OUTLINES只能針對(duì)某個(gè)SQL ID，如果存在一些沒(méi)有使用綁定變量的情況，就沒(méi)辦法通過(guò)SQL ID來(lái)指定OUTLINES。而往往一個(gè)系統(tǒng)中，這些SQL才是最常用的，也是最重要的。在OUTLINES的實(shí)現(xiàn)上，如果可以通過(guò)SQL指紋來(lái)設(shè)定，那么OUTLINES將會(huì)有更廣泛的用途。

第五個(gè)需求是長(zhǎng)時(shí)間運(yùn)行的SQL執(zhí)行進(jìn)度可視化，提供一個(gè)類(lèi)似于Oracle V$SESSION_LONGOPS的外部接口視圖。不過(guò)希望能夠比Oracle提供更多一些的信息。比如當(dāng)前這個(gè)操作來(lái)自于哪個(gè)執(zhí)行計(jì)劃（執(zhí)行計(jì)劃指紋），以及這個(gè)操作處于執(zhí)行計(jì)劃的第幾個(gè)步驟。當(dāng)然這種SQL執(zhí)行進(jìn)度可視化僅僅顯示長(zhǎng)時(shí)間執(zhí)行的操作，只有當(dāng)執(zhí)行計(jì)劃中的某個(gè)算子執(zhí)行成本超過(guò)一定閾值的時(shí)候，才需要輸出到接口中，否則這種輸出會(huì)影響SQL引擎的效率。這部分功能實(shí)現(xiàn)只要到某個(gè)算子級(jí)別就可以了，不需要做SQL級(jí)別的，SQL引擎還是性能為先，可視化是次要的。

其實(shí)SQL引擎中的優(yōu)化器是改進(jìn)難度最大的部件，需要有大量的應(yīng)用案例來(lái)促進(jìn)其優(yōu)化和改進(jìn)。而且有些優(yōu)化器的功能優(yōu)化難度極大，要做出一個(gè)優(yōu)秀的CBO優(yōu)化器其實(shí)不是一朝一夕就能夠完成的。不過(guò)在優(yōu)化器達(dá)到完美之前，必須是夠用的。也就是能夠盡可能讓我們的開(kāi)發(fā)人員不要總是面臨SQL不改寫(xiě)就無(wú)法正常運(yùn)行的困境。用戶的應(yīng)用場(chǎng)景十分復(fù)雜，因此作為國(guó)產(chǎn)數(shù)據(jù)庫(kù)的開(kāi)發(fā)者，集中力量去解決必須解決的問(wèn)題，剩下的問(wèn)題通過(guò)HINT，OUTLINES這樣似乎不是太智能化的手段來(lái)彌補(bǔ)優(yōu)化器的能力不足，也是必須的。不管怎么說(shuō)，能夠解決用戶問(wèn)題的數(shù)據(jù)庫(kù)就是好數(shù)據(jù)庫(kù)。