“天底下没有完美的数据库，也许Oracle是个例外”，前阵子几个DBA在讨论国产化替代时，有人就这么说。确实是的，Oracle算是比较完美的数据库产品了，不过现在很多用户都在面临从Oracle数据库向其他数据库迁移的问题。中国电信已经宣布了今年年底前全线下架Oracle数据库，全部用国产或者开源数据库替代。本周和中国电信的朋友交流的时候，他们说已经完成了数百套系统从Oracle数据库的迁移，最晚到8月份，这个任务就能够完成了。
还有些企业怕遇到坑，因此还在不断地研究、认证、测试、分析中。事实上，在做出决策之前多一分小心还是十分必要的。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的时候会报错：
openGauss2.0是不支持这个语法的，openGauss3.0也类似，只不过错误信息有所变化：
在openGauss3.0中，针对ustore的表是支持covering index的，而针对默认的和PG兼容的ASTORE是不支持的。于是我们做了些变更，创建了一个测试用例。
[code]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=10 and id=10 and id=10 and id=10 and id=10 and id |
