数据库国产化替代之后，补坑之路从未止步……
d
白鳝约 7 分钟
白鳝约 7 分钟
还有些企业怕遇到坑，因此还在不断地研究、认证、测试、分析中。事实上，在做出决策之前多一分小心还是十分必要的。10年前电信提出用开源数据库替代Oracle的时候，针对MYSQL和PG做了一番分析，我也参与了其中的一些工作，通过对当时的MYSQL和PG进行对比，我们最终的分析结果是：如果要迁移计费、账务系统，MYSQL优于PG。当然这个分析并不是说MYSQL就全面碾压PG，而只是针对计费、账务这样的系统场景，PG的膨胀与VACUUM会对系统稳定运行造成较大的影响，相对而言风险更大。
其实我们也没办法看得太远，哪怕是选择好的数据库，在迁移过程中，甚至迁移完成后的长期运行过程中，还是会遇到很多坑。有些问题可能是数据库基础架构从娘胎里带来的，无法马上解决的问题。如果你的应用对这样的问题十分敏感，不解决会引发大问题，那样就十分悲惨了。
昨天刚刚上班就有一个客户遇到国产数据库的问题，他们有一条SQL执行十分频繁，总体开销很大，希望通过index only scan来降低开销，不过创建了索引之后，执行计划依然不走index only scan，还是要走需要回表的执行计划。我以前也没有遇到过这类的问题，正好这个国产数据库是基于opengauss 2.0的，我们的测试环境中有opengauss 2.0和3.0的环境。于是我就先在opengauss 2.0的环境中做了一个测试。实际上openGauss是不支持Covering index的，在openGauss 2.0上，我们创建Covering index的时候会报错：
在openGauss3.0中，针对ustore的表是支持covering index的，而针对默认的和PG兼容的ASTORE是不支持的。于是我们做了些变更，创建了一个测试用例。
drop table test_covering ;create table test_covering (id serial,name text,val int);create index idx_test_covering on test_covering(id,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';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;
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;
当VM里已经更新了PAGE的信息，那么这些PAGE上的记录就不需要“回表操作”了，因此VACUUM后VM得到了更新，此时HEAP FETCHES变成0了，说明没有任何回表操作。因为VM文件的大小远远小于数据表的文件，因此不回表会降低执行成本。从上面的例子我们也可以看出，不回表执行0.037毫秒，回表执行0.203毫秒，差异还是挺大的。
在PG 11上只要做了表分析，那么起码执行计划是Index Only Scan的，为什么openGauss上执行计划也不选择Index Only Scan呢？刚才我们测试openGauss的时候因为不支持Covering Index的问题，对SQL做了改写。改写后的SQL在PG 11上是什么样的呢？
我们发现，如果索引变成了普通的索引之后，在PG上的执行计划也和openGauss一样了。
不过如果我们做一个vacuum，执行计划就变得正确了，而且也不存在“回表”的问题了。从这个测试我们再联想一下openGauss，openGauss数据库的CBO优化器是不是认为因为VM比较旧，这个查询需要回表，所以不选择Index Only Scan的执行计划呢？
于是我们也在openGauss上做了VACUUM，不过VACUUM完成后，可视的PAGE数量还是0，执行计划也还是没有发生改变。过了一段时间后，发现可见页的数量不为零了，于是再次分析执行计划，发现执行计划已经变成了Index Only Scan。
openGauss的文档上对于VM文件更新的问题并未做出说明，因为我们也只能猜测openGauss的vacuum命令并不更新VM文件，VM文件的更新可能是由其他机制来完成的。因为这个问题的存在，因此openGauss在ASTORE上不支持Covering Index，以防止创建了这样的索引，大部分情况下，Index Only Scan的执行计划也不可用。不过我们在openGauss的相关文档上并未找到这方面的说明。
我们利用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;
数据库使用过程中难免会遇到坑，在使用“完美的数据库”-Oracle的时候我们不也经常遇到BUG吗。遇到坑并不怕，怕的是遇到坑之后我们无法找到解决方案，也不知道这个坑到底是怎么回事。国产数据库并不只是在功能与性能上存在差距的问题，更大的问题可能是在今后的长期维护上，运维知识、运维专家、运维工具的缺失可能会更大地影响国产数据库的发展。
不过不管如何，走出第一步就没有后退的道理了，遇到坑就退回去也是不大可能的。企业在走出第一步之前，就应该未雨绸缪，安排好填坑的队伍，这样才能有备无患。