上周参与了 IFClub 社区的一场直播活动，话题为“我心中的兼容性”。可以说兼容性是近些年来非常火热的一个话题，直播也吸引了很多观众的观看与参与。在直播中，与薛老师、尹老师就兼容性话题做了深入的探讨，两位老师妙语不断，给我不少启发。本文正是根据直播中的部分观点整理而来，也算是个人对兼容性的一些新思考。

1. Why-为什么讲兼容性

在数据库国产化进程中，兼容性议题始终是不可回避的一个核心问题。其根源是来自于产业链两端不可调和的现实困境与生存诉求。一方面用户侧承受着数十年技术债务枷锁，另一方面厂商侧则深陷生态位争夺的防御性竞赛；可以说是技术债务与生存壁的双重逻辑，共同将兼容性由技术特性推升为战略刚需。

1)用户侧：历史积累的刚性约束

从用户侧来看，企业面临的最大困境在于历史技术资产的凝固化沉淀。过往二三十年里，大量关键核心业务系统深度耦合于特定数据库体系，形成三重维度（人、财、技）的迁移屏障。一是人力资本固化，企业数据库技术团队的能力模型高度特性化，从SQL与PL/SQL开发范式到专属管理工具的操作经验，从性能调优方法论到容灾方案的实施流程，技术人员的知识体系与原有平台深度绑定。这种数十年培养形成的智力资产无法通过简单培训迁移，导致人才转型成本呈指数级增长。二是财务沉没成本，从高端存储的硬件高额资产投入，到已投入的海量定制开发功能模块所带来的难以消化的成本，在财务视角下，兼容性成为对冲资产减值的唯一缓冲器。三是架构遗产负担，业务系统间复杂的接口调用如同布满暗线的雷区，存储过程嵌套的专属函数、调度任务依赖的系统包、BI工具配置的特定语法，这些深度嵌入业务逻辑的技术细节，构成比代码迁移更危险的隐形债务。缺乏有效兼容层的情况下，牵一发而动全身的改造风险，往往迫使企业维持旧有技术栈，形成制约创新的反向枷锁。

2)厂商侧：生态竞争的生命线

对数据库厂商而言，兼容性能力已超越技术特性范畴，演变为市场攻防的战略武器。这种定位源于三重生存法则的强力驱动。一是作为一种防御性功能的产品壁垒，当客户已构建成熟的数据库技术生态时，兼容能力成为置换决策的关键砝码，这也是来自用户侧的刚性需求。这种低切换成本优势能有效阻止竞品渗透，使兼容层演变为事实上的用户锁定机制。二是内卷市场的生存法则，行业竞争压力催生独特的兼容性军备竞赛。当竞品宣称兼容率达到特定阈值时，跟随者被迫在技术指标上对标甚至超车，进而研发资源被迫倾斜到兼容性追赶。三是来自现实市场侧的准入需求，很多招标的技术评分体系中，兼容性要求已成为关键门槛指标。从语法覆盖度到系统视图一致性，从管理接口匹配度到容灾方案等效性，这些可量化验证的细项构成技术标的核心分数区。厂商必须投入重金建设兼容能力矩阵，以跨越采购准入的硬性门槛。

2. What-什么是兼容性

在数据库领域，兼容性通常指新产品与原有产品（如Oracle、MySQL等）在功能、行为、接口上保持一致或相似的能力，进而降低迁移成本、减少学习曲线和业务中断风险。然而，兼容性并非一个简单、统一的概念。传统理解往往将其狭隘地局限于语法或对象层面的匹配（例如SQL语句能否直接运行），却忽略了兼容性是一个涉及多角色、多层次的复杂体系。正因为如此，也导致国产数据库在兼容性实现上差异显著，同时由于缺乏行业统一标准，导致用户评估时易陷入片面认知。

1)标准定义缺失，传统理解狭隘

兼容性在数据库领域长期缺乏权威定义，导致用户和厂商对其理解碎片化。传统观点常将兼容性简化为“语法是否支持”或“对象是否可迁移”，这种狭隘视角造成两个误区：误区一是过度追求形式兼容，许多用户期望新产品能100%还原原数据库行为，但现实中不存在完美兼容，在国产数据库中常需等价改写（如通过工具转换），而非原生支持。强行追求形式兼容可能忽略语义等价性，如计算结果精度、排序规则等细微差异。误区二是忽略角色差异需求。兼容性评估常集中于开发者视角（如函数、语法），却忽视运维、架构和决策层的诉求。这导致运维者在管理、监控、迁移时面临工具链断裂；决策者关心的成本、性能、生态、硬件依赖更少被纳入兼容性范畴。因此，兼容性需跳出单维视角，从多角色层次重新定义。

2)兼容性新定义，四维层次框架

从上面来看，兼容性应定义为“一个涵盖开发、运维、架构和决策四维层次的全方位评估体系”。这里我将兼容性分为四个层次、三类角色来看待。

1.png

• 面向开发者（DEV）的兼容性，这里主要是对语法、函数以及过程化语言的兼容性。开发者关注代码级无缝迁移，核心是语法支持度和函数覆盖度。这其中有几点需要注意：一是提供的兼容能力，是原生兼容还是等价兼容，后者还需开发者来主动改写；二是除了简单意义的语法兼容，更重要的语义方面的兼容（即SQL语句的行为是否一致）；三是内置函数的兼容情况，它会直接影响数据处理效率和完整性；四则是之前忽略太多的过程化语句的支持，相较于前者，过程化语言的迁移更加复杂，投入成本也更高。
• 面向管理者（DBA）的兼容性，这里又可细分为面对开发DBA和运维DBA两类。前者更多是关注与开发相关的兼容能力，包括有数据对象、数据类型、字符集、数据字典及最为核心的SQL引擎能力。这方面很多厂商都提供了工具实现针对对象和数据的迁移能力，这方面也相对比较成熟；但比较缺少的是SQL引擎能力的兼容评估，特别是针对常见场景的处理（如Oracle中ACS等）及对应能力（如Oracle中的Outline、Profile等）。后者则是更多关注与运维相关的兼容能力，包括从日常运维、备份恢复、性能优化、高可用、监控告警、诊断排障等等。这方面的兼容性通常是被厂商所忽略的，因为其底层实现机理不同，导致此类的兼容性也比较难于实现；但这些能力对于DBA来说是很重要和关键的。例如针对性能优化常见的AWR、ASH的能力，DBA快速定位分析问题就很必要；在比如备份恢复中的快速闪回能力，也能帮助DBA快速恢复异常。
• 面向决策者（MANAGER）的兼容性，此类兼容是更多是一种广义上的兼容，或者认为是兼容性的扩展，也是之前被忽略最多的。这里面包括有成本（TCO）、技术风险、周边生态、规划战略、硬件环境等。这其中的内容比较宽泛，举了例子。例如实现国产数据库迁移后，其TPS/QPS表现和总拥有成本如何（即所谓的TCO），如果是通过大量堆砌硬件来实现性能等价兼容，那么其TCO不可能太好，而对于企业来说这点使不得不去考虑，不要出现上的去，用不起的情况。

总结下，兼容性绝非简单意义上的语法匹配，而是一个需从开发者（代码）、运维者（管理）、决策者（战略）多层次综合定义的体系。未来兼容性评估应坚持务实原则，根据不同视角来来客观地看待兼容性问题，选择那些真正具有“平滑、安全、低成本”的产品作为基础，来推动技术自主创新。

3. Question-为何兼容性乱象多

前面我们谈到了为什么谈兼容性及兼容性的定义，这些也是基于当前行业内兼容性乱象多的客观情况。相信大家很多体会，兼容性在数据库领域被频繁提及并被吐槽，其背后的原因是什么呢？这里总结了四点：

1)兼容性没有统一标准

乱象根源之一在于行业缺乏统一标准导致定义混乱，各厂商自建体系难以横向对比。用户可以在不同厂商的对外材料里看到针对兼容性的描述，然后却没有一个共识性的全集，导致用户在兼容性认知上都没有可依据的规范。而在产品层面各家实现也是五花八门，例如有的厂商采用的“租户级兼容”用来区分不同模式，而有的则采用参数来切换兼容模式。这种碎片化定义使用户陷入认知迷雾，到底兼容性包含哪些？实现的兼容标准又是什么？

2)缺少必要的度量手段

兼容性评估的度量手段匮乏加剧了问题。当前更多依赖厂商自证，很多厂商也都提供了此类兼容性评估工具，然而这些工具都存在诸多不足。一是能力方面的缺失，仅能支持上述谈到的兼容性能力中的一小部分，如大多数迁移评估工具仅支持静态分析语法转换，无法验证动态场景下的执行结果等价性；二是评判标准也是个黑盒子，无法针对目标库做完整的评估。

3)夸大宣传进一步扭曲现实

更严峻的是市场宣传与实现能力的严重错位——技术实现需要数年投入，市场窗口却稍纵即逝。这种矛盾导致行业陷入参数虚标、选择性演示的恶性循环，真实兼容水平与宣传口径形成巨大的灰色地带，商业竞争催生的话术陷阱充斥市场。于是我们可以看到诸如大谈“全面兼容Oracle”，却不谈兼容了哪些、兼容度多少、怎样去度量的等一系列问题。这种营销驱动的技术叙事，本质上是用局部真相掩盖全局短板。

4)预期过高成为致命的最后稻草

甲方用户也常常执着于“零改造”幻想，要求产品100%兼容，全然无视产品间的差异，不可能存在两款完美兼容的产品。这种执念衍生出三重错配：一是严重低估兼容性范围，完全依赖厂商黑盒工具做评估，导致上线后问题频出；二是忽视隐性成本投入，错误将改造迁移理解为数据库简单更换而已，完全没有考虑可能相关的软件开发、硬件购买、生态适配、人员培养等相关成本投入；三是天然忽略了架构差异，常见地将原有集中式架构设计完全照搬到分布式数据库，完全没有考虑其特殊性。

4. How-如何破解兼容性困局

兼容性困局的破解需行业、厂商、用户三方协作，抛弃空泛承诺，回归务实路径。

1)行业侧：明确范围，建立标准

行业侧必须建立可量化的兼容标准，终结当前各厂商自说自话的乱象。例如制定SQL语法覆盖度（如Oracle的500个高频语句支持率）、语义一致率（同一查询结果差异阈值）等硬性指标，并公开测试用例，用户便能客观对比国产数据库的真实兼容能力。同时推动工具革新：以动态验证替代静态语法检查。此外强制厂商公开“兼容范围”与“改造清单”，要求明示其兼容的各种细节，而非笼统宣称“高度兼容”。

2)厂商侧：放弃空谈，回归务实

厂商侧则需摒弃百分比话术，从底层能力做起并公开透明。兼容性工作量巨大下，没必要追求完美，必须有所取舍；聚焦高频核心需求，并明确其功能边界如何。厂商应提供分层兼容列表，针对如上述兼容层次中所谈到的兼容性，分别给出详细的兼容说明，不兼容的情况也要给出等价方案或修改建议等，这样反而会赢得用户信任。

3)用户侧：降低预期，理性客观

用户侧要降低预期，以资源换质量，用实测揭标签。兼容性绝非“零成本”魔法，用户需客观看待兼容性本质：部分“兼容”实则是技术债转嫁（如以触发器模拟物化视图刷新）或违背最佳实践（如分布式数据库强求不考虑分片设计）。唯有通过亲自动手，通过真实场景测试验证其兼容性能力。