“天底下沒有完美的數(shù)據(jù)庫，也許Oracle是個例外”，前陣子幾個DBA在討論國產(chǎn)化替代時，有人就這么說。確實是的，Oracle算是比較完美的數(shù)據(jù)庫產(chǎn)品了，不過現(xiàn)在很多用戶都在面臨從Oracle數(shù)據(jù)庫向其他數(shù)據(jù)庫遷移的問題。中國電信已經(jīng)宣布了今年年底前全線下架Oracle數(shù)據(jù)庫，全部用國產(chǎn)或者開源數(shù)據(jù)庫替代。本周和中國電信的朋友交流的時候，他們說已經(jīng)完成了數(shù)百套系統(tǒng)從Oracle數(shù)據(jù)庫的遷移，最晚到8月份，這個任務(wù)就能夠完成了。

還有些企業(yè)怕遇到坑，因此還在不斷地研究、認(rèn)證、測試、分析中。事實上，在做出決策之前多一分小心還是十分必要的。10年前電信提出用開源數(shù)據(jù)庫替代Oracle的時候，針對MYSQL和PG做了一番分析，我也參與了其中的一些工作，通過對當(dāng)時的MYSQL和PG進(jìn)行對比，我們最終的分析結(jié)果是：如果要遷移計費(fèi)、賬務(wù)系統(tǒng)，MYSQL優(yōu)于PG。當(dāng)然這個分析并不是說MYSQL就全面碾壓PG，而只是針對計費(fèi)、賬務(wù)這樣的系統(tǒng)場景，PG的膨脹與VACUUM會對系統(tǒng)穩(wěn)定運(yùn)行造成較大的影響，相對而言風(fēng)險更大。

其實我們也沒辦法看得太遠(yuǎn)，哪怕是選擇好的數(shù)據(jù)庫，在遷移過程中，甚至遷移完成后的長期運(yùn)行過程中，還是會遇到很多坑。有些問題可能是數(shù)據(jù)庫基礎(chǔ)架構(gòu)從娘胎里帶來的，無法馬上解決的問題。如果你的應(yīng)用對這樣的問題十分敏感，不解決會引發(fā)大問題，那樣就十分悲慘了。

昨天剛剛上班就有一個客戶遇到國產(chǎn)數(shù)據(jù)庫的問題，他們有一條SQL執(zhí)行十分頻繁，總體開銷很大，希望通過index only scan來降低開銷，不過創(chuàng)建了索引之后，執(zhí)行計劃依然不走index only scan，還是要走需要回表的執(zhí)行計劃。我以前也沒有遇到過這類的問題，正好這個國產(chǎn)數(shù)據(jù)庫是基于opengauss 2.0的，我們的測試環(huán)境中有opengauss 2.0和3.0的環(huán)境。于是我就先在opengauss 2.0的環(huán)境中做了一個測試。實際上openGauss是不支持Covering index的，在openGauss 2.0上，我們創(chuàng)建Covering index的時候會報錯：

openGauss2.0是不支持這個語法的，openGauss3.0也類似，只不過錯誤信息有所變化：

在openGauss 3.0上，我并沒有看到預(yù)期的Index Only Scan的執(zhí)行計劃。于是我在網(wǎng)上和一個朋友交流了這個問題，他正好對此有過研究，立即就指出了這是一個visibility map的問題，PG 8.4為了支持MVCC，引入了visibility map。不過VM文件并不是實時更新的，因此如果PAGE在VM中是不可見狀態(tài)時，就必須做回表操作，因為索引中并不存在數(shù)據(jù)行可見性的標(biāo)識數(shù)據(jù)，因此不能使用Index Only Scan。為了進(jìn)一步確認(rèn)這個問題，我在一個社區(qū)版的PG 11上做了一個測試。

drop table test_covering ;

create table test_covering (id serial,name text,val int);

create index idx_test_covering on test_covering(id) include(val);

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

analyze test_covering;

update test_covering set val=val+1;

select relallvisible from pg_class where relname='test_covering';

select relallvisible from pg_class where relname='test_covering';

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

vacuum test_covering;

select relallvisible from pg_class where relname='test_covering';

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

我們在PG 11上看到了預(yù)期的執(zhí)行計劃，因為PG的數(shù)據(jù)行的可視性信息僅僅存儲于表數(shù)據(jù)中，而索引中沒有這個信息，因此在做Index Only Scan的時候，如果VM沒有及時更新，就必須回表才能獲得準(zhǔn)確的信息了。在VACUUM前執(zhí)行的查詢中，HEAP FETCHES是180,說明雖然執(zhí)行計劃是Index Only Scan，不過有180條數(shù)據(jù)是回表操作了。

當(dāng)VM里已經(jīng)更新了PAGE的信息，那么這些PAGE上的記錄就不需要“回表操作”了，因此VACUUM后VM得到了更新，此時HEAP FETCHES變成0了，說明沒有任何回表操作。因為VM文件的大小遠(yuǎn)遠(yuǎn)小于數(shù)據(jù)表的文件，因此不回表會降低執(zhí)行成本。從上面的例子我們也可以看出，不回表執(zhí)行0.037毫秒，回表執(zhí)行0.203毫秒，差異還是挺大的。

在PG 11上只要做了表分析，那么起碼執(zhí)行計劃是Index Only Scan的，為什么openGauss上執(zhí)行計劃也不選擇Index Only Scan呢？剛才我們測試openGauss的時候因為不支持Covering Index的問題，對SQL做了改寫。改寫后的SQL在PG 11上是什么樣的呢？

我們發(fā)現(xiàn)，如果索引變成了普通的索引之后，在PG上的執(zhí)行計劃也和openGauss一樣了。

不過如果我們做一個vacuum，執(zhí)行計劃就變得正確了，而且也不存在“回表”的問題了。從這個測試我們再聯(lián)想一下openGauss，openGauss數(shù)據(jù)庫的CBO優(yōu)化器是不是認(rèn)為因為VM比較舊，這個查詢需要回表，所以不選擇Index Only Scan的執(zhí)行計劃呢？

于是我們也在openGauss上做了VACUUM，不過VACUUM完成后，可視的PAGE數(shù)量還是0，執(zhí)行計劃也還是沒有發(fā)生改變。過了一段時間后，發(fā)現(xiàn)可見頁的數(shù)量不為零了，于是再次分析執(zhí)行計劃，發(fā)現(xiàn)執(zhí)行計劃已經(jīng)變成了Index Only Scan。

openGauss的文檔上對于VM文件更新的問題并未做出說明，因為我們也只能猜測openGauss的vacuum命令并不更新VM文件，VM文件的更新可能是由其他機(jī)制來完成的。因為這個問題的存在，因此openGauss在ASTORE上不支持Covering Index，以防止創(chuàng)建了這樣的索引，大部分情況下，Index Only Scan的執(zhí)行計劃也不可用。不過我們在openGauss的相關(guān)文檔上并未找到這方面的說明。

我們利用openGauss 3.0的USTORE功能，做了最后一個實驗，因為剛才我們看到openGauss在USTORE上是支持covering index的，是不是用Ustore可以解決這個問題呢？

drop table test_covering ;

create table test_covering (id serial,name text,val int)  with (STORAGE_TYPE=USTORE) ;

create index idx_test_covering on test_covering using ubtree(id) include(val) ;

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

analyze test_covering;

update test_covering set val=val+1;

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

和我們預(yù)想的一樣，在USTORE上不需要VM的情況下，優(yōu)化器正確地選擇了Index Only Scan。似乎在opengauss上使用USTORE可以完美解決這個問題。不過目前USTORE還不夠成熟。在USTORE上也存在不少坑，比如說官方文檔中沒有提及的USTORE表不支持回收站的問題，以及USTORE上以前我們遇到的一些性能問題。從openGauss僅在USTORE上支持covering index上，我們也可以看出華為openGauss在VM方面可能存在一些問題。就像我們測試中發(fā)現(xiàn)，哪怕做vacuum，也不能馬上更新VM數(shù)據(jù)。不能及時更新VM，會導(dǎo)致SQL語句的回表操作增加，導(dǎo)致covering index的初衷無法實現(xiàn)。

數(shù)據(jù)庫使用過程中難免會遇到坑，在使用“完美的數(shù)據(jù)庫”-Oracle的時候我們不也經(jīng)常遇到BUG嗎。遇到坑并不怕，怕的是遇到坑之后我們無法找到解決方案，也不知道這個坑到底是怎么回事。國產(chǎn)數(shù)據(jù)庫并不只是在功能與性能上存在差距的問題，更大的問題可能是在今后的長期維護(hù)上，運(yùn)維知識、運(yùn)維專家、運(yùn)維工具的缺失可能會更大地影響國產(chǎn)數(shù)據(jù)庫的發(fā)展。

不過不管如何，走出第一步就沒有后退的道理了，遇到坑就退回去也是不大可能的。企業(yè)在走出第一步之前，就應(yīng)該未雨綢繆，安排好填坑的隊伍，這樣才能有備無患。