数据库信创替换已经是很多企业必须面对或者正在面对的问题，而且对于很多企业来说已经不仅是找几套不太重要的小系统替换一下试试的问题了。对于核心系统的数据库替代来说问题不大，企业可以投入大量的资金、人力和时间来认真做这件事。反而是大量大型的，关键系统的替代不那么容易。因为这些系统的替代一方面还是存在一定难度，另外一方面这些系统如果出问题，还是会对企业的业务有所影响的，而更讨厌的是，这样的系统数量很多，如果都按照核心系统那么投资来干，地主家也干不起。
不知道是不是因为这个原因，做信创数据库替代的企业领导十分喜欢听到数据库厂商提出“平替”这个概念，数据库厂商也投其所好，说自己的产品能够“平替”Oracle。久而久之很多企业的不太懂数据库的管理者们就认为数据库平替不是一件很难的事情了。我甚至遇到过一个企业的领导提出用RDS MYSQL “平替” Oracle，他认为Oracle和MySQL的SQL都基本上符合SQL 1999的标准，没理由RDS替不了Oracle。
互联网企业一直兜售把业务回归应用来释放数据库，从而降低对系统对数据库的要求。实际上极少数传统企业的IT部门能够真正地学会互联网企业的研发技巧，实际上里面暗藏的一些东西互联网企业们并没有向客户说清楚，那就是这个逻辑背后是对研发的数倍成本的投入，以及企业被软件开发商的深度绑定。我曾经遇到过一个企业，他们顺应甲方领导的思路，把应用系统从Oracle迁移到阿里云RDS MYSQL上，用了几十个RDS数据库替换以前的一个Oracle数据库，为此他们针对这套系统专门开发了一个分库分表的数据库路由中间层。我和他们交流的时候问他们为什么要费时费力做这些事情，弄得不好这个项目可能会做亏了。他看着我笑了笑说：“现在吃点苦是值得的，通过这个项目，我们的研发能力提高了一大截。从另外一个角度来看，我敢说这个系统上线的时候，就是甲方离不开我们的时候了，钱不一定都赚在一时”。我想这个哥们从自己企业的角度来考虑这件事，肯定是没错的，但是如果甲方的领导听到这句话会不会脖子后面冒凉风啊。
事实上企业在做大量的数据库“平替”的时候，并没有给应用改造和系统迁移留下多少经费，因此“平替”工作仅仅从应用兼容性来考虑就可以了，对于大多数系统来说平替后虽然慢了一些，但是还可以忍受。实在忍受不了的，再做些优化就可以了。大不了把这些问题遗留给运维，让运维慢慢去解决好了。
不过对于核心系统或者次核心系统来说就没那么简单了，企业的决策者不能只是用“平替”这两个字来对待了。如果不能在数据库迁移替换时做足功课，那么将会是后患无穷的。比如说我们要把一个系统中的Oracle数据库替换成基于PG的国产数据库。如果国产数据库做了一些Oracle数据库语法兼容的工作，那么数据库迁移替换工作会十分顺利。甚至有些国产数据库连PL/SQL的兼容性都很好，那样情况下，迁移就更顺利了。不过迁移完成后，大量的性能问题就冒出来了。
实际上做数据库迁移的时候不仅仅要考虑兼容性，还要考虑二者之间的一些技术差异，要想办法弥补国产数据库的缺陷。比如对于PG数据库来说，一些WHERE 条件带or的SQL，如果以前Oracle上的执行计划使用HASH JOIN效果很好，到了PG或者PG兼容的国产数据库上，就只能走NESTED LOOP了。如果JOIN的表数据量很大，返回的结果集也很大，那么迁移时就必须对SQL进行改写，否则迁移后的性能必然是无法接受的。此类SQL数量不多，如果在迁移之时做些测试，企业很容易就能梳理出来，在迁移时把这些SQL改写好，那么迁移工作也就顺利多了。
除此之外，我们还需要充分利用开源或者国产数据库的优势能力。还是以Oracle向PG或PG兼容的国产数据库迁移。PG数据库的索引种类比Oracle要丰富得多，如果选用得当，那将会事半功倍。这时候如果应用开发人员能够配合DBA进行索引的优化设计，将会让迁移工作更加顺利。另外如果我们的某些数据的写入和访问带有时序特性的，那么迁移到PG的时候直接用timescaledb的表来存放，设计好自动分区的策略和老数据压缩的策略，那么这部分的数据访问效率也会大大的提高。
在数据库迁移替代工作中，能够“平替”肯定会大大节约迁移的成本，但是我们不能因为“平替”能力的存在而放弃优化工作，否则就会为今后的长期应用与运维埋下一株邪恶的毒草。
