先说成本这件事
关于数据库替换这件事，我个人始终觉得很多人对它的难度存在严重的低估。
很多人一听说要换数据库，第一反应是"那不就是导个数据吗？"——这种朴素的理解不能说完全错，但确实只看到了冰山一角。你跟他说这个成本很大，他觉得你在吓唬人，是在帮原有数据库厂商说话，是在制造焦虑，是屁股决定脑袋。
我有时候也很无奈。真正干过这件事的内行，心里都清楚这个活儿有多苦、多碎、多么不讨好。但在外行人眼里，这事儿就变成了"导出导入一下"的问题。你要是跟他解释，这个事情不简单.否则你想想这么容易的话：“哪个领导没有这个觉悟？”
现实就是，除了头部金融客户、少数实力雄厚的运营商，以及业务场景相对简单、稳定性要求不是那么高的企业，大量的替换工作至今没有完成，或者完成了但一直在"缝缝补补"地运行着。这不是觉悟问题，这是现实问题。
很多人说，这是过去老一辈技术不行、欠下的债。但你看看今天，新一代的替换需求依然在持续发生，该踩的坑一个没少，该交的学费一分没免。所以这不是历史遗留问题，这是数据库替换这件事本身的基因决定的——它就是一个高成本、高风险、低容错的系统性工程。
应用软件才是真正的门槛
为什么数据库替换这么难？因为它不像换操作系统，也不同于换CPU。操作系统和CPU是底层基础设施，应用软件往上跑就行了，换个硬件平台，应用该跑还是跑，至多是性能上的差异，不会出现功能性问题。
但数据库不一样。数据库是应用软件的"衣食父母"——所有业务数据的增删改查，都要经过数据库这条管道。你上去以后跟数据库打交道的，不是运维，不是DBA，是开发人员。开发人员把业务需求转换成SQL语句，往上执行，最后落地到数据库里。
这里就出现了一个根本性的问题：开发人员水平参差不齐，而数据库替换这件事，恰恰是对"代码质量"的一次全面体检。
好的开发团队，SQL写得规范、逻辑清晰、索引合理，这种代码迁移到新数据库上，出问题的概率相对可控。但现实是，大多数团队里，SQL质量本身就是一笔糊涂账——有些查询走全表扫描、有些事务不提交不回滚、有些连接不释放、有些分页写得随心所欲。这些代码在原数据库上跑的时候，可能刚好能work，能用，不出问题，你也不知道它写得多烂。
但一旦换了数据库，这些积累了几年的"技术债"，会在新环境里集中爆发。语法兼容是第一个坑，性能表现是第二个坑，行为差异是第三个坑，层层叠叠，绵绵不绝。
兼容性这东西，分为两种
厂商宣传兼容性，这个我见得太多了。
几乎所有数据库厂商都会告诉你，“我们的兼容性是99%，甚至100%”——有些更狠的，说超过100%。Oracle自己也只能做到100%，它居然超了。你问他怎么超的，他不回答，PPT翻到下一页了。
但这里有一个根本性的混淆：能运行，和能正常运行，是两回事。
我见过太多这样的场景了：SQL语句在新数据库上不报错了，CREATE TABLE能跑了，INSERT UPDATE DELETE都顺了，大家都松了一口气，觉得迁移成功了。然后呢？然后某一天，业务高峰期来了，一个看似简单的关联查询，在新数据库上跑了三十秒，原来是毫秒级的。然后开发人员问：“为什么会这样？”
这就是我说的"性能兼容性问题"。
语法兼容、性能兼容，是两个完全不同的维度。前者你可以相信厂商说的90%多、100%，后者——这是解决不了的。你让厂商来调，他跟你说这是SQL写法问题；你让开发来改，他说这个SQL在原来数据库上就是这么写的，从来没出过问题。两边互相踢皮球，最后这个锅就挂在半空中，没人接。
所以我跟很多人在交流的时候会说：语法兼容这个方面，你大可以相信厂商说的数据，90%也好、120%也罢，都能解决。但是性能和可观测性这两个维度，那差距是客观存在的，而且是不好解决的。
但这两个维度，偏偏是日常里最不被关注的。
性能这件事，在过去几十年被多少人真正重视过？
说实话，有多少开发人员真正关心过一条SQL的执行计划？
这个问题我问过很多人，大多数人的反应是：“执行计划？什么执行计划？”
你再问他，索引怎么选、JOIN顺序怎么看、什么时候该加hint，大多数时候得到的回答是——“这个不是我关注的，我们有DBA。”
好，有DBA。DBA负责性能，DBA负责优化。但问题在于，当你要换数据库的时候，你有多少DBA能对新数据库的优化器有足够的了解？你的开发人员写的那些SQL，有多少是在老数据库上靠着"蒙对了索引"才跑通的？
迁移到新数据库，优化器变了，执行计划的生成逻辑变了，原来那个碰巧work的SQL，到了新环境里，可能就变成了一场灾难。而你甚至不知道灾难从何而来，因为执行计划这玩意儿，在没有足够经验的情况下，你根本看不懂，也没法优化。
这才是数据库替换真正的坑。
可观测性，这个词大家都会说，真正做到的没几个
除了性能兼容性，还有一个被严重低估的问题：可观测性。
什么是可观测性？简单说就是，当你的数据库出现问题的时候，你能不能快速定位问题在哪里。慢查询是谁干的？锁等待是什么情况？会话数为什么突然飙升？资源消耗的瓶颈在哪里？
在老的、成熟的数据库上，这些工具是完善的、有文档的、有社区积累的，你知道去哪里找、怎么查。但到了新的数据库上，很多工具要么缺失，要么行为不一致，要么根本没有社区积累，全靠厂商给你解释，而厂商的解释往往又滞后于实际问题的发生。
我经常遇到这样的场景：迁移完成后，系统跑起来了，大家松了一口气。然后某天，生产环境出了一个性能问题，开发人员问："这个慢查询怎么分析？“结果发现新数据库的慢查询日志格式跟原来不一样，分析工具也不一样，请厂商支持，厂商说"我们在做这个工具的研发”。
这种时刻，你会特别怀念老数据库那些看起来不起眼、但实际很管用的基础功能。
先上去再说，不行再换——这句话的代价
说到这里，我想聊聊一个很普遍的心态：先上去再说。
很多人面对数据库替换的时候，态度是务实的——先上，跑着看看，有问题再说，不行再换。这种心态不能说完全错，但它有一个隐含的前提：你有足够的缓冲空间和试错成本。
现实是，上了生产以后，发现问题此起彼伏，一个接一个。今天解决了一个，明天又冒出来两个。这边语法兼容了，那边性能掉下去了；这边索引重建了，那边存储过程跑不动了；这边参数调了，那边执行计划崩了。运维团队天天加班，DBA天天被叫去"救火"，业务方天天问"什么时候能稳定"，领导层开始质疑这个决策。
这时候你跟领导说：“要不再换一个？”
没有人会云淡风轻地说"换"。之前说"不就是导个数据吗"的那批人，这时候全都沉默了。
所以我一直有一个观点：数据库替换这件事，门槛不是在技术方案上，门槛是在"预期管理"上。你换之前把话说清楚，比换之后被追着问"怎么办"要强一百倍。但很可惜，大多数项目在启动的时候，没有人愿意听这些话，都觉得是在泼冷水，是在唱反调，是在为旧势力站台。
只有真正踩过坑、交过学费的人，才知道这些话的分量。
一个真实的例子
我亲身经历过这样一件事。
有人把一个业务系统从一个数据库迁移到某国产数据库上，结果建表都建不上去——不是语法问题，是数据类型映射的问题，一堆特殊的数据类型在新数据库里找不到对应的类型，要么改字段，要么换方案。折腾了半天，总算建上了。
然后，索引又不行。某些索引类型不支持，某些索引语法报错，有些索引在新数据库里的行为跟原来完全不一样——同样的查询条件，原来走索引快如闪电，换过来之后全表扫描。
我看了这个情况，跟对方说：“要么就这么用？”
对方问：“这样能用吗？”
我没有直接回答。我心里清楚，这后面还不止多少坑呢。能不能预估风险？能预估一部分，但完整的风险清单，没人能列得出来。这不是技术问题，这是数据库替换这件事本身的不确定性——你永远不知道下一个坑在哪里，直到你踩到它。
所以有的时候我宁愿在迁移之前多做一点评估，多测一些场景，把丑话说在前面，也不要等到上了生产之后，被问题追着跑。被动挨打的感觉，是非常消耗团队士气的。
走两步，没事走两步
说到这里，我想回到一个最朴素的观点：
有的时候，说很多，不如做一下。
数据库替换之前，与其看厂商的宣传资料，听厂商的PPT讲解，不如自己动手测一测。拿你真实的业务SQL，拿你真实的业务场景，跑一遍新数据库，看看语法报不报错、性能掉不掉、结果对不对、执行计划是什么样子。
这一步，谁都省不了。
厂商给你看的TPC-C数据、TPC-H数据，那些是标准化测试场景，跟你的实际业务可能差了十万八千里。你的SQL长什么样、你的数据分布是什么规律、你的并发模型是什么特点——这些只有你自己测了才知道。
走两步，没事走两步。这句话放到数据库替换这件事上，是非常实在的建议。
不要被PPT上的数字唬住，也不要被"100%兼容"的说法吓退，自己拿真实样本测一测，用结果说话。
这才是数据库替换这件事，最正确、最务实的打开方式。
