国产数据库替换，先换哪一套

2027 年 12 月 31 日，是国资委 79 号文给央企和国企划的线：核心信息系统要在那之前完成国产化替换。

文件是 2022 年发的。前面几年，多数单位先换办公电脑、操作系统和邮件。数据库放在最后，因为它离账本最近。

2026 年 9 月，采购单突然密了起来。江苏银行花 1884 万买国产数据库服务器，杭州市的全市信创一朵云预算 1.5675 亿元，上海航空工业 205.82 万，江西洪都 98.8 万，北京市农业农村局 148.75 万买金仓。

10 月，中船集团一次集采 500 套国产数据库。这些单子放在一起看，说明替换已经从试点进入批量交付。

留给单套系统慢慢试的时间，比前两年少了。

一、2027 年这个日期，为什么现在才动

信创是信息技术应用创新的简称，说得直白一点，就是政府和大企业把原来用的国外软硬件，逐步换成国产的。

数据库是里面最难换的一件。服务器换了，应用改一改还能跑；数据库换了，数据要搬，程序要改，性能要重新验。

很多单位不是不想换，是不知道从哪一套开始。换早了怕出事，换晚了怕赶不上节点。

这一篇只讲顺序。哪家厂商好不好，要按自己的系统去验，别人替不了。

二、先数清楚：要换的不是一套库，是一串系统

很多单位说换数据库，脑子里想的是一套库。真到动手，账本、订单、客户、报表、接口，各自一套，互相还连着。

所以第一步不是选厂商，是列清单。每个系统写清五件事：用的什么数据库、数据有多大、每天多少笔、能停多久、谁在维护。

清单拉出来，往往会发现三成系统已经没人维护，两成系统连源代码都找不到了。

这些系统不该跟着一起换。先决定停用、保留还是重写，再谈搬数据库。

数据库替换最贵的不是软件许可，是那些看不见的依赖。

三、三类系统，不能按同一个顺序换

把所有系统分成三级，顺序就出来了。

级别	里面有什么	什么时候换	能停多久
第一级：内部报表和查询	经营报表、历史查询、内部看板	先换	可以停一个周末
第二级：重要业务	订单、库存、客户、审批	第二批	只能停几分钟
第三级：核心账务	收款、付款、总账、清算	最后换	最好不停

这张表不是按系统大小排的，是按出错以后赔多少排的。

先从赔得少的地方练手，把迁移流程走顺，再碰赔得多的。

四、先换报表库，原因不是它不重要

报表库最适合当第一站，原因有三个。

第一，它读得多、写得少，出问题可以第二天重跑。第二，它和核心系统通常只有一条数据同步，断开影响面小。第三，它的数据量大，正好能试出迁移工具和磁盘够不够。

先换报表库，还能顺手拿到一个读数：同样一条查询，新旧两套各跑多久。这个数比厂商给的测试报告可信。

等报表库跑稳一个季度，再动订单和库存。

五、Oracle 和 MySQL，迁移难点不一样

从 Oracle 搬走，难点多在存储过程和优化器。存储过程是一段写在数据库里的程序，业务逻辑常藏在里面。

Oracle 的序列、同义词、包、提示语法，各家国产库的支持程度不一样。表面能建表，不代表程序能跑。

从 MySQL 搬走，难点多在细节。字符集是数据库认字的规则，排序规则决定同样的字怎么排队。再加上自增主键、事务隔离级别、日期精度、大小写敏感，每一项都可能让同一条语句给出不同结果。

还有驱动和连接池。应用连数据库的那一层如果不换，很多问题会在上线后才冒出来。

六、兼容性不能只看语法能不能跑

厂商演示时，通常拿一个简单系统跑一遍，语句都能过。回到自己的系统，第一周就会撞上没覆盖的写法。

兼容性要验四层：建表和数据类型、查询语句、存储过程和触发器、应用连接方式。

最容易被漏掉的是第四层。数据库换了，驱动没换，或者连接池版本太旧，应用会在并发高的时候断开。

验的时候不要挑最干净的系统，挑一个用了八年、没人敢改的老系统。它能把问题一次暴露出来。

七、数据怎么搬：五步，每步都能停

第一步，全量搬一次，只搬结构和小表，先看工具认不认。

第二步，搬全量数据，记录用了多久、占了多少磁盘。这一趟决定正式迁移的停机窗口有多长。

第三步，搬增量。业务还在跑，新产生的数据要能追上。多数工具用日志或者时间戳做增量，选哪种要看源库支持什么。

第四步，新旧两套一起跑，只让旧系统对外服务。新系统每天接收同样的数据，第二天对数。

第五步，选一个低峰窗口，把读请求转到新系统，旧系统保留只读，随时能退回去。

每一步都要有停止条件。数对不上就停在原地，不要带着疑问往下走。

八、新旧两套一起跑，最怕数不一样

一起跑的那几周，每天上午第一件事是对数。

对数不要只对总数。总数一样，明细可能错位。至少要比三层：总行数、按天的合计、随机抽一百条明细。

差异要能解释。是同步晚了几分钟，还是字段精度丢了，还是业务在两套系统里各写了一次。解释不了的差异，一条都不能留。

对数的人要固定。今天一个人、明天一个人，差异记录就会断。

九、性能验收要拿自己的慢查询去测

厂商的测试报告只能当参考，因为数据分布和查询写法都是他们的。

验收时把自己最慢的二十条查询拿出来，在新库上跑一遍，记录耗时、扫描行数、占用内存。

还要测混合负载：报表在跑的时候，下单还能不能在要求的时间里返回。单条查询快，不代表一起跑还快。

测试数据量要接近生产。拿十万行测出来的结果，放到一亿行上不成立。

十、高可用和备份，换库时最容易漏

旧库的主从、备份、监控，通常已经跑了几年。新库上线时，这些要重新接一遍。

先确认三件事：主库坏了多久能换上、备份能不能恢复出一份完整数据、出问题谁来看。

备份不要只做一次恢复演练。每个月抽一天，把备份恢复到另一台机器，让业务的人随便查一张表。

高可用不是买了就能用。换库演练没做过，真出事时没人敢按那个按钮。

十一、运维工具要重新接一遍

数据库换了，监控、巡检、慢查询分析、权限审批这些工具，多数要重新适配。

最容易被忽略的是告警规则。旧库的阈值照搬到新库，可能天天误报，最后被人关掉。

上线前把告警分三级：影响业务的、需要当天看的、可以第二天看的。每级都要有人收。

运维交接要写成一页纸：常见问题怎么查、找谁、多久能到。

十二、合同里要写的四件事

第一，兼容性验收到什么程度。不要写「基本兼容」，要写清楚哪些语句、哪些程序、哪些接口必须跑通。

第二，迁移责任是谁的。厂商只交工具，还是派人驻场，出了差异谁负责查。

第三，服务时限。出故障多久响应、多久到场、多久给出原因。

第四，退出条款。用了两年发现不合适，数据怎么拿回来，许可证怎么算，过渡期有多长。

这四件事在签合同前写，比上线后争更有用。

十三、预算不只软件钱

一套国产数据库的报价，通常只是软件许可。真正花钱的地方还有三块。

第一块是服务器。国产库对国产芯片的适配更好，原有服务器可能要一起换。

第二块是人。迁移工具要人用，性能要人调，运维要人接。一个核心系统，至少要有两个人从头跟到尾。

第三块是停机。停机窗口越长，业务损失越大。前面量出来的迁移时间，要乘一点五留余量。

把这三块加进去，再和原厂的续费比，账才算完整。

十四、选厂商看三样

第一看同类系统的案例。不要只看有没有案例，要看案例跑了几年，是不是还在用。

第二看服务。国产数据库出问题，多数要靠厂商的人到场。本地有没有服务团队，比总部的奖状重要。

第三看活得久。数据库要用五到十年，厂商如果两年后不在了，迁移和运维都会成问题。

这三样都要在合同和公开信息里找证据，不要只听销售讲。

十五、一张按系统分级的替换表

系统	先做什么	验收读数	退路
报表与查询	全量迁移，周末停机	二十条慢查询耗时、每天对数	旧库保留只读一个月
订单与库存	新旧两套一起跑两周	每分钟下单量、库存差异为零	读请求转回旧库
客户与审批	先换从库，再换主库	登录成功率、审批时长	旧库保留一个月
核心账务	最后换，选季度末之后	日终对数、清算金额一致	季度内可退回

这张表里最右边那一列最重要。没有退路的系统，不要先动。

十六、上线前必须能答的三个问题

第一，新库坏了，业务多久能恢复，谁有权做这个决定。

第二，数对不上，先查哪三张表，找谁一起查。

第三，用了一个月发现性能不够，退回去要多久，数据会不会丢。

三个问题答不出来，说明还没准备好。答案要写在纸上，不能只在某个人脑子里。

十七、这一轮的决定

国产数据库替换不是一次采购，是一场持续两三年的搬家。

顺序比厂商重要。先把报表和内部系统搬过去，把流程、工具、人练熟，再动核心账务。

2027 年的节点不会因为哪一家没准备好而往后挪。现在能做的，是先把清单列出来，把第一套系统选对。