信创数据库迁出评估复盘：迁进去八个月，迁出来要两年

各位，今天聊个实在的。

几年前，我参与过一个项目，把一套核心系统从老库迁到国产库。工期八个月，上线平稳，后来还拿去做过行业分享，算得上标杆。今年那家单位被集团并购，要求技术平台统一，这套系统得迁到集团指定的另一个平台上。

我被叫回去，帮着做了一次迁出评估。结论不好看：当年迁进来花了八个月，现在要迁出去，保守估计两年，还不一定迁得干净。回头看，当年我们只算了进来的账，没算出去的账。

一、选型会上，几乎没人问"将来怎么出去"

信创改造这几年，大部分精力都在回答一个问题：能不能迁进来。性能够不够、兼容率高不高、案例多不多，问得很细。很少有人反过来问一句：五年以后要迁出去，代价有多大。

我把这个代价叫退出成本。它不是财务概念，是技术现实。一套系统一旦被某一家的语法、工具、数据格式绑住，将来想换，换的就不只是数据库，是围绕它长出来的整个生态。麻烦在于，这笔账在选型表上几乎没有位置。大家比的是性能够不够、案例多不多，很少有人会问一句"将来怎么走"。等到真要迁出去，才发现代价在第一天就已经埋下。

评估项	迁入时看什么	迁出时看什么	为什么容易漏
语法	兼容率、能不能跑通	多少 SQL 依赖了专有扩展	迁入只求跑通，不记录依赖
数据	能不能导进去	能不能以开放格式全量导出	私有备份格式没人验证过
工具	配套工具好不好用	工具链绑得有多深	工具越多越方便，也越难拆
授权	现在多少钱	五年后扩容多少钱	按核计价，扩容是笔隐形账

二、锁定的四种形态，一个比一个隐蔽

第一种，语法锁定，是最表面的。迁移的时候，工具会把老库的语法转成新库能认的。这里有个容易被忽视的细节：转译过去的目标，多半就是新库自己的方言，标准 SQL 反倒少。你每用工具"兼容"一次，就多欠一笔方言的账。将来再迁，这些方言又成了新的路障。

第二种，存储过程和自研函数，是绑得最深的地方。为了赶某个逻辑，团队往往用新库的 PL 扩展去写函数和包。逻辑越复杂，写得越顺手，绑得越死。我见过一家保险公司的理赔模块，单条存储过程两千多行、嵌套七层。这种代码，迁一次要脱层皮，迁第二次一点不会更轻松。

第三种，专有特性。分区表的写法、物化视图、JSON、数组类型、全文检索、GIS，还有这两年热起来的时序、向量、多模。这些能力大部分是各家的私有实现，标准里根本没有。业务用它们跑得越快，将来搬家的成本越高。厂商推的"创新特性"越多，越要想清楚哪些是刚需，哪些只是"有就行"。

第四种，周边生态，最隐蔽。同步工具、监控、备份、审计、开发插件，一套一套都是同一家的。单看每一件都好用，合在一起就是一堵墙。数据库本身或许还能换，围绕它长出来的这圈工具，拆起来比数据库本身更费劲。

形态	表面看	真实情况	怎么识破
语法锁定	兼容率高，迁得顺	兼容的是一堆专有方言	问有多少 SQL 用了非标准语法
逻辑锁定	逻辑都写进了库，性能好	大量 PL 函数、包、触发器	数一数库内的代码行数
特性锁定	用上了高级特性	私有实现，标准里没有	逐条问：这个特性搬得走吗
生态锁定	配套工具齐全	监控、备份、审计全套同厂商	接口是标准的，还是私有协议

三、最要命的那一笔，在数据导出上

如果只让我留一个自检项，我会留"数据能不能以开放格式导出去"。

很多厂商的备份是私有格式。用它的工具备份，就得用它的工具恢复。平时感觉不到问题，反正都是自己用。可一旦要迁走，你会发现：数据都在，就是没有一个干净、标准、第三方工具能直接读走的版本。

那套系统就是这样。当年备份方案图省事，选了厂商套件。这次要迁出，工程师翻了两天备份文件，最后结论是：想要一份完整的开放格式数据，只能重写导出脚本，逐表、逐类型地导，碰上专有类型还得单独转换。光这一步，就吃掉了评估的大半时间。

四、案例复盘：八个月，对两年

接着说那套系统，把账摊开看。

逻辑这一层，早年为了性能改写的一批专用函数和包，评估下来大约三分之一要重写。数据这一层，专有备份格式重新导出加校验，预估两个月。应用这一层，散落各处的方言 SQL，得全量梳理一遍。工具这一层，监控和审计要换到集团的平台，接口重新对接。

这些是当时评估的口径，具体到天可能有出入，量级上应该差不多。坐下来细想，当年我们比的是兼容率，现在才明白：兼容率越高，用得越顺手，欠它的也越多，将来反而越难走。

这话说得有点绝对。兼容率本身是好事，问题在于它让迁入顺滑的同时，也把迁出变重了。选型时光看兼容率这个数，看不出这层。

五、选型阶段，怎么给退出成本打分

我整理了一张退出成本评估表，四个维度，每个维度看它是"开放"还是"私有"。私有项越多，将来越难抽身。

维度	要问什么	达标信号	危险信号
数据	能否以标准格式全量导出	有独立的导出方案，不依赖厂商工具	只有私有备份格式
逻辑	有多少业务逻辑写进了库内	逻辑主要在应用层	大量 PL 函数、包、触发器
特性	用了多少专有高级特性	只用标准能力	深度使用私有分区、类型、扩展
生态	周边工具有多绑定	用标准协议对接	监控、备份、审计全套同厂商

再给一个经验值：迁出成本大约是迁入的一点五到两倍。道理简单，迁入有人帮你，厂商要给案例、要驻场、要承诺；迁出没人帮你，得自己一寸一寸地拆。

六、出发前，四条清单过一遍

这套库的数据，能不能用第三方工具独立导出，不依赖厂商的备份软件？备份是开放格式，还是私有格式？
有多少业务逻辑和专有特性，沉淀在了库里面？存储过程、函数、分区、专有类型，逐个量化过吗？
监控、审计、开发工具，是不是全套绑在同一家？授权按什么计价，五年后扩容要多少钱，算过吗？
这一条，是我自己踩过的坑：选型阶段一定要让厂商当场演示"用第三方工具把数据完整导出去"，别只听他说支持。我见过一家，方案里写着"支持标准导出"，真让他导一次，专有字段全变成了乱码。支持标准，和标准地支持，是两回事。

写在最后

信创改造走到今天，大家已经不缺"能不能用"的判断了。缺的是"将来好不好走"的清醒。一套系统，装进来容易，等它长出自己的根，再拔就难了。选型的时候多花半小时问一问退出成本，大概比多比一个跑分有用。

各位在选型时，算过退出成本这笔账吗？假如现在让你把这套库换掉，你觉得要多久、会卡在哪一步？评论区聊聊，给正在选型的朋友提个醒。

我是老徐，关注我，咱不聊虚的，只聊真正跑过生产环境的东西。