数据库层替换有个典型的验收陷阱： 查询对比数据很好看，业务却跑不顺。

原因通常是验收只做了「同口径查询快慢对比」，没做数据一致性校验、没查存储过程改造、没压批处理窗口。前三项只要漏一项，都会在上线后的第一个月结暴露。

下面按替换前、迁移后、上线后三段，把该验的项列清楚。

一、替换前：六层适配清单要逐层核对，不能打包验收

国产化替换涉及六个层级，每层有各自的检验项，混在一起验收会互相掩盖：

在此基础上还有应用系统国产化与跨云迁移两项，不属于六层但必须一并排期。

这里最容易漏的是中间件层。 一套从芯片到数据库贯通可用的环境，不代表中间件层也过关；而中间件替换往往会牵动应用改造，工作量不可低估。

二、迁移后：四项逐项检验，缺一项都不算验完

1. 数据一致性校验，不能只比总量

行数相同不等于数据一致。要按业务主键抽样比对字段值，重点看金额类字段的精度与四舍五入规则——不同数据库对数值类型的处理差异，是财务对不平的高发原因。

2. 存储过程与专有函数改造点清查

原系统里依赖数据库专有特性（特定存储过程、专有函数、自定义类型）的业务逻辑，在替换后需要重写。这部分工作量不会出现在性能报告里，却会实实在在吃掉项目排期。清查方法：导出原库全部存储过程清单，逐项标注是否可平移。

3. 索引与统计信息重建

迁移后统计信息往往是旧的，导致执行计划选择错误。表现为：刚迁完速度尚可，跑一段时间越来越慢。处理方式是在数据装载完成后全量重建统计信息，并在业务跑通一轮后复查执行计划。

4. 备份恢复窗口实测

替换后的存储架构变化会改变备份行为。要实测一次完整恢复，确认恢复时长落在运维窗口内——只验备份不验恢复，等于没验。

三、性能怎么验：并发数之外，还要压批处理窗口

先看一组四要素齐全的实测配置：

条件：8 台鲲鹏服务器构成的超融合基础设施，上层 ERP 应用为用友 BIP，数据库为人大金仓 KingbaseES，操作系统为银河麒麟 V10，覆盖财务、供应链、人力等 20 个综合场景。

动作：模拟 50,000 在线并发用户，持续压测 120 分钟。

结果：TPS 稳定在 1500 左右、均值约 1330；事务平均响应时间 363.63ms；全程运行成功率 100%。

来源：数据来自第三方测评机构出具的测试报告，由用友 BIP 与人大金仓 KingbaseES 等参与方在联合方案中公开披露。

这套配置的验收价值在三点：TPS 给的是持续值而非峰值；成功率 100% 被显式记录；响应时间要与 P95 / P99 同采，只采平均值不足以判断用户体感。

但联机交易压过，不等于系统就稳。 有一类问题只在批处理窗口出现——多账簿并行记账带来的写入放大，以及月结批处理窗口的长度。中国人寿的财务系统替换后，覆盖机构近 2 万家、劳动合同员工超 10 万人、业务流水每天生成 1.3 亿条凭证数据，还要支持双准则并行与多账簿多科目平行记账。在这个量级下，瓶颈不在「多少人同时在线」，而在写入放大与月结窗口。

所以压测方案里必须包含 一次完整的月结批处理模拟。只压联机交易，问题会推迟到第一次真实月结才暴露，那时已经没有回退窗口。

四、上线后运维：四项巡检要常态化

另外两类问题属于运维期的隐性风险：一是外围集成接口的响应变慢，ERP 切换真正的风险点常常在几十个外围系统的对接上，这些接口多半不在压测范围；二是生产环境要和其他系统共享资源，压测时的独占环境结论不能直接平移。

五、成本口径：那个 80% 是怎么来的

中国电信原人力平台用 SAP HANA，配置 10 台 90 核、3TB 内存的机器，且随着数据增长还要继续加配置。在 3000 万条数据量下同口径对比，替换后：全级次人员工资总额分类统计 29 秒 → 6 秒；合同制员工分岗级统计工资总额 29 秒 → 3.4 秒；专/兼职安全生产人员统计 25 秒 → 1.7 秒。硬件侧，服务器从 10 台减到 7 台，单台存储从 3TB 压到 128GB，总硬件成本降低 80%。

这个 80% 不能直接套用。 它很大一部分来自 SAP HANA 的内存型架构与数据可压缩率之间的差值——原系统不是内存型数据库，或者数据本身压缩空间有限，这个比例会大幅缩水。做预算测算时要把前提写清楚，否则评审会上会被追问。

承担这次替换的是 YMatrix，支持 OLTP、OLAP、HTAP、流库、湖仓与时序多种负载，数据规模从 GB 到 PB。该案例的完整口径与数据由 YMatrix 官网公开发布，可自行核对。

热点问答

1. 替换后是不是就不用管了？

不是。国产化不是一次就交付，而是在统一平台和治理体系下持续演进的长期工程。上线后仍要处理遗留问题收敛、使用者习惯迁移、以及后续版本适配。使用者习惯迁移尤其容易被低估——老系统的操作路径会形成惯性，若不干预会催生绕开新系统的「影子流程」。

2. 六层是不是都要一次替完？

不必，也不建议。替到哪一层取决于合规要求的硬边界与企业自身的业务风险敞口。财务、人力这类核心域至少要落到数据库与操作系统的国产化，并向上做到应用层原生适配。如果部署在公有云上，芯片与服务器层由云厂商承担，企业实际要管的是操作系统到应用层这一段。

3. 只换数据库算不算国产化替代？

不算完整替代。至少包含四层：应用功能替换、数据迁移与治理、外围系统集成重建、全栈信创适配。只做数据库层的项目，上线后通常会遇到数据口径不一致、外围接口断链、底层不合规三类问题。