数据库管理-第397期 国产数据库的兼容性，是不是必须？（20251217）

数据库管理-第397期 国产数据库的兼容性，是不是必须？（20251217）

作者：胖头鱼的鱼缸（尹海文） Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP，ITPUB认证专家 圈内拥有“总监”称号，非著名社恐（社交恐怖分子） 公众号：胖头鱼的鱼缸 CSDN：胖头鱼的鱼缸（尹海文） 墨天轮：胖头鱼的鱼缸 ITPUB：yhw1809 IFClub：胖头鱼的鱼缸 除授权转载并标明出处外，均为“非法”抄袭

本文无AI生成内容，请放心食用

似乎，这个问题是数据库圈内一直讨论的问题：一部分人认为，国产数据库做好（一定程度的）兼容性，是进入市场的敲门砖；另一部分人则觉得，做兼容性是一件无意义的事情，国产数据库就该做出基于自己特性的产品，让历史数据和应用代码来适配它。

我认为可以从好几个角度来看待这件事情。

如果你是要互联网行业从业者，在数据库（关系型数据库）中你使用最多的功能大概率就是CRUD，关于众多其他特性往往不会去触碰，性能、功能不够，就加上一些对应的其他类型数据库或数据中间层即可。造成这一现象的原因是IT是互联网行业的收益产生部门，需要去不间断的适配不断变化的需求，在数据库的层面就需要能够支撑应用的快速迭代，所以大概率会选择功能单一的数据（库）产品来快速实现功能需求后整合，而不是选择一个复杂的数据库来深度学习并使用；即便使用一些功能全面的数据库，但是对这些功能的使用模式也会相对独立。这其中还可能有另一个深层次的原因是不想被某种技术栈深度绑定。

但如果你在传统行业，你就会发现你的应用很多在深度数据库使用数据库能力，这其中一个很重要的原因就是传统行业IT是成本部门，不会有非常大的功能迭代需求，有时候也会控制其投入。这也就注定导致了传统行业不会同互联网行业那样选择复杂的IT架构，那样会要求更强的架构与开发人员，也需要更多的IT基础设施（包括软件技术栈和硬件）。另一方面，同互联网公司需求、功能相对独立，可以通过单元化来拆分数据；传统行业往往各个系统/流程/阶段/(or whatever）深度绑定，这也导致了各个部分的数据会深度关联，数据一致性和快速响应的要求也不适合用复杂的数据层技术栈来拆分，充分深入了解并使用一种数据库的众多特性来适配传统行业的应用场景反而是一种成本集约的手段。

这时候做互联网行业或者使用互联网行业思维的同学肯定要跳出来说了，这和兼容性有啥关系，如果花点精力、花点人力、花点时间，让历史数据和应用代码来适配新的国产数据库，甚至是去使用互联网行业IT架构，这几乎就是在重构原有的应用，在一些愿意投入的企业中确实是这么做的。但问题就是在这里，还是回到上一段，更多的传统行业IT投入没有那么大，不可能在换数据库（甚至是换IT架构）这件事情上花太多的钱（也就代表了精力和人力），举个例子，有客户领导就会提出：这么搞我一个系统前面十多年的投入岂不是打水漂了。另一方面，因为一些其他且更重要的因素，在很多场景中也没有那么多时间来做这件事情。

因此，对于许多传统行业的客户来说，数据库国产化的要求就是要业务应用代码改动少，甚至是不改动，能够平滑的切换到国产数据库。需要的是没有代码改造压力、极少停机切换影响、没有性能焦虑，其中除了做好数据同步和数据库性能优化以外，最重要的就是兼容性了。在切换完国产数据库后，依然能同之前深入使用国外商业数据库一样，逐步的深入使用国产数据库，优化IT架构，但这一定不是现阶段做的事情！

最后回过头来看兼容性，我们不能只是站在自己的视角来看国产数据库，甚至不能以技术优劣和发展趋势来看。用数据库的兼容性来适配千家万户企业以低成本方式加速数据库国产化改造，这才是当下最重要的事情。