金仓数据库迁移实战：人力资源系统信创改造全记录

这两年做企业信息化项目，绕不开的一个词就是“信创”。我们手上这套人力资源管理系统，就是在国产化替换的大背景下，完成了从传统商业数据库向金仓数据库的迁移改造，最终交付了一套能稳定跑在日常业务里的国产信创解决方案。文章里没有任何炫技的东西，全是实际迁移过程中的踩坑记录、技术选型思路和可复用的操作细节，希望对正在做类似事情的同行有点帮助。

如果你所在的公司或单位也面临“存量系统国产化适配”的任务，或者你是负责数据库选型的DBA、被派来改代码的Java开发、要评估方案的项目经理，这篇应该能帮你少走不少弯路。我会从“为什么要这么干”讲到“具体怎么落地”，把金仓数据库在人力资源这种典型业务系统里的真实表现摊开来说。

1. 这个项目到底在解决什么问题

1.1 我们收到的任务和真实痛点

先交代一下项目背景。我们单位的人力资源管理系统已经跑了多年，功能上覆盖员工信息、部门编制、考勤、薪酬、招聘、培训、绩效这些常规模块。系统本身是Java写的，原来用的是商业数据库，部署在自有机房。业务本身不算复杂，但作为核心人事系统，数据敏感度高、外部门对接多、月底薪酬核算和考勤统计对稳定性要求很高。

真正的推动力来自外部环境的变化。一方面，商业数据库的授权和服务费用逐年上涨，每次谈续约都耗费大量精力；另一方面，信息化系统国产化适配已经成了行业共识，很多单位在制定整体替换计划的时候，会优先把人力资源、办公这类系统列为第一批试点对象。人力资源系统有个优势：业务边界清楚、用户量可控、数据量不算夸张，小步快跑，失败了也容易回滚，所以特别适合做“信创适配的第一块试验田”。

我们拿到这个任务的时候，不只是“换一个数据库”那么简单。领导层关心的是整个技术栈能不能国产化，包括服务器操作系统、中间件、数据库，以及在信创目录产品名单里选型。而落到技术团队层面，我们更关心的是：存量数据如何无损迁移，应用代码要改多少，性能能不能守住原来的水平线。说实话，当时团队心里也没底，毕竟数据库不像换个依赖包那么简单，它会影响SQL语法、驱动、事务行为、字符串排序、时间格式等一大堆细节。

1.2 为什么人力资源系统适合当替换试点

很多同行问我，为什么选人力资源系统而不是某一个非核心的小系统来做信创试点？我当时的判断是这样的：一个替换试点系统要有代表性，可真不能选一个只有两张表、一个月也没几个人用的边缘系统。人力资源系统虽然不像交易系统那样高并发，但它具备典型的信息化系统特征——有复杂的主数据模型，有批量计算任务（薪酬、考勤），有审批流，有大量报表查询，还有外部门系统的对接需求，数据权限和字段安全也很敏感。把这些都适配好了，以后再换财务、合同、供应链这类系统，团队就已经跑通了一套流程，心理压力和价值感完全不同。

另外，人力资源系统的用户行为模式也适合做渐进式切换。晚上加班的人少，节假日更是空窗期，我们可以选择在月底业务相对平稳的窗口期做割接，降低业务影响。这一点在后面谈上线策略的时候还会细说。

1.3 信创选型为什么最终锁定了金仓数据库

在数据库选型阶段，我们其实认真比较过几款主流国产数据库，包括达梦、openGauss、金仓等等。每家的特点都很鲜明。达梦在金融政务存量Oracle系统上适配经验丰富；openGauss社区活跃、技术文档开放；金仓给人印象最深的是它对Oracle兼容模式的投入程度，以及配套数据迁移工具的成熟度。

我们最终选择金仓，有几个直接原因。第一，我们原有系统虽然是Java开发，但SQL写法多多少少带了一些商业数据库的风格，比如存储过程、序列、字符串函数、行号分页这些写法。金仓的Oracle兼容模式对这些语法的接受度高，改造成本明显低。第二，它的迁移工具链对“业务系统+数据库”这种整体迁移场景支持得比较好，能批量完成结构转换和数据搬迁，不用我们手工写一堆脚本。第三，金仓在信创目录产品名单里，对单位后续的项目验收、审计流程来说更加省事，这也是选型时一个非常现实的因素。

结论就是：技术兼容性、工具完备度、生态合规性三者都满足，那就果断定它。

2. 金仓数据库选型与整体方案设计

2.1 金仓数据库到底是个什么来历

这里给不太熟悉国产数据库的朋友补个基础认知。金仓数据库，通常指的是人大金仓的KingbaseES，它是一款关系型数据库管理系统。它在产品内核层面做了不少自研工作，同时对外兼容多种主流数据库的语法和行为特性，部署形态上支持单机、主备、集群等多种方式。

对我们应用开发团队来说，最关键的一个概念是“兼容模式”。金仓数据库在创建数据库实例或数据库的时候，可以设置兼容模式，常见的有Oracle模式、PostgreSQL模式、MySQL模式。也就是说，同样一条SQL，在不同的兼容模式下，解析规则和行为表现会有差异。我们这套HR系统原本有比较浓的Oracle风格，所以建库的时候选了Oracle兼容模式。如果你原来的系统是MySQL体系的，建议也先搭个小环境，用MySQL兼容模式跑一遍，看看到底哪种更贴合你的代码，不要想当然。

顺带说一个版本相关的经验：金仓数据库不同大版本的行为细节是有差异的，比如系统函数命名、驱动包版本、管理员账号初始化方式。我们实施的时候用的V8系列，建议新项目直接咨询厂商拿最新的稳定版，不要自己到网上随便抓一个老版本，后面踩坑了会很被动。

2.2 方案设计：应用适配与数据库迁移双轨推进

项目一开始，很多人以为这就是DBA的活，把数据导过去就完事了。真正动手后才发现，人力资源系统涉及那么多模块，数据库结构几十张表，存储过程、触发器、视图、序列、定时任务全都有，必须把“数据库迁移”和“应用适配”两条线完整组合起来，整体方案才算闭环。

我们的做法是分成四个阶段：

• 清单梳理阶段：把所有数据库对象导出，归类整理成表、视图、存储过程、触发器、序列、函数、定时任务清单，同时跑一遍应用日志，找出实际使用的SQL模板。
• 兼容性验证阶段：在测试环境搭好金仓数据库，把核心模块的SQL拿出来跑一遍，记录所有不兼容点和报错信息。
• 迁移与改造阶段：先做一次全量结构迁移，再灌入脱敏后的生产数据，应用代码改驱动、改连接池、改SQL方言，逐个模块做功能测试。
• 割接与固化阶段：窗口期停机，停旧库写操作，做最后一次全量数据同步，切换连接，启动新系统，然后持续观察一两个业务周期。

这里要重点讲一下为什么强调“双轨推进”。如果先等数据库迁完再让应用团队介入，时间上肯定会浪费；如果应用团队不等数据库环境准备好就埋头改代码，又会发现很多SQL兼容性判断根本没法验证。正确的节奏是：数据库迁移脚本每完成一个阶段，立刻让应用开发在这个环境上跑一个模块；应用侧每改完一批SQL，立刻反映到迁移脚本的转换规则里。两份工作彼此喂数据，项目才会滚动起来。

2.3 系统的部署架构与基本形态

人力资源系统本身的架构不算复杂，但在国产化替换里，部署形态也需要提前说清楚。整体上就是三层结构：前端应用部署在Tomcat等中间件上，业务逻辑集中在Java应用层，数据库单独部署在金仓数据库服务器上，数据落盘在本地磁盘或者共享存储上。

如果你正好也要做类似替换，我给你一个建议：先把架构画成一张清晰的拓扑图，把每一个组件的版本号、网络连接方式、端口、依赖关系都写清楚。我见过太多项目，数据库换完了才发现应用那边还有一台定时任务服务器连的是旧库地址，或者某个报表系统还依赖一个旧的只读账号。只有把依赖关系摸全了，才能避免漏网之鱼。

2.4 兼容性评估要关注的几个维度

在正式动工前，我们专门做了一份兼容性评估清单。这个清单的价值怎么强调都不为过，它决定了后续的工作量和风险分布。这里把我的版本分享给你。

评估维度	常见风险点	我们采取的应对措施
表结构	字段类型差异、字符集、默认值、自增列	用类型映射表校对，测试环境逐表核验
SQL语法	分页、字符串拼接、日期函数、多表更新	先跑SQL静态扫描，再抽核心SQL实跑
存储过程	语法差异、异常处理方式、包机制	优先改成应用层逻辑，必须保留的做手工改写
序列与自增	主键生成方式变化	转换为数据库序列或兼容自增机制
驱动与连接池	JDBC驱动版本、URL格式、连接池探活SQL	统一驱动，调整Druid配置参数
事务行为	隔离级别、锁机制、并发控制行为	应用层压测，重点验证薪酬批量提交场景

做完这份评估，其实整个项目的改造量已经能估个八九不离十。我特别推荐你也用这种“先评估后动手”的方式，而不是上来就导出脚本导数据。

3. 人力资源系统数据库改造：表结构、SQL与存储过程

3.1 HR系统核心表结构梳理与建模要点

既然要改造，第一步肯定是把HR系统的核心表结构梳理清楚。人力资源系统的表大致可以分为几类：基础档案类、流程业务类、计算报表类。典型的基础档案包括部门表、岗位表、员工信息表；流程业务类包括招聘流程表、入离职申请表、请假加班审批表、培训记录表；计算报表类则包括考勤明细表、薪酬计算表、社保公积金表、绩效评分表。

表结构本身决定了后面迁移的难易程度。如果你负责的HR系统有“一张大宽表”的毛病，比如把员工的几十个属性全部塞进一张表，那我建议在迁移期间顺手做一次规范化拆分，哪怕只是逻辑视图层面的拆分，也比硬撑着迁移好。为什么？因为国产数据库的优化器对宽表的统计信息和行估算能力，跟你原来熟悉的商业数据库不完全一样，宽表在复杂查询下更容易出性能问题。

还有一点，员工信息表里的敏感字段，比如身份证号、手机号、工资卡号，我们全部做了加密处理。这个策略在迁移前后要保持一致：先解密再迁移是最不可取的做法，最好是把密文直接迁过去，业务层继续保持原有加解密逻辑，避免敏感数据在迁移链路里明文暴露。

3.2 数据类型映射与SQL方言改造

类型映射是数据库迁移里最机械但也最容易出错的部分。举几个我们实际遇到的情况。

• 整数类型：原来用tinyint存储状态位，金仓里对应smallint或直接int，0和1的语义不受影响。
• 字符串类型：原来的varchar2或varchar指定了长度，金仓的varchar长度单位是字符，一般直接对应。
• 大文本字段：如通知公告的正文，原来可能是longtext或clob，金仓里用text或clob都可以，关键是驱动读写方式要匹配。
• 日期时间：原来习惯用datetime或timestamp，金仓标准用法是timestamp，存储精度和格式化函数要留意。
• 金额字段：涉及薪酬的数据一律用numeric，千万别用浮点类型，这个在任何数据库里都是铁律。

SQL方言的改造更是细碎活。我捡几个最典型、出现频率最高的差异点说说。

分页查询是一个老生常谈的话题。原来的写法可能是limit ?, ?，在Oracle兼容模式下就会遇到麻烦。金仓兼容模式下更稳妥的写法是用fetch first rows only，或者继续用带行号的方式。我当时在项目里定了个规则：所有分页SQL统一走应用框架的分页插件，不允许大家手写带方言特性的分页语句，这样代码里的改动量瞬间少了很多。

字符串拼接也要注意。习惯用concat函数的没问题，但如果你原来写的是'a' + 'b'这种形式，到金仓就需要改成'a' || 'b'。类似的还有group_concat函数，在Oracle兼容模式下得改成listagg，或者用string_agg，具体看兼容模式定。

再说一下分批Update的改造。人事系统常有“给某个部门所有员工的岗位等级批量上调一级”这种需求，原来习惯写成update a join b on ... set ...，这种从一个表关联更新另一个表的写法，在Oracle兼容模式下并不受欢迎。最保险的方式是改写成两步：先查子集，再对主键列表执行update，或者在应用层循环处理。虽然代码看起来长了，但兼容性最好，事务控制也更清晰。

3.3 序列、主键自增与存储过程迁移

关于主键生成，这是很多人第一次用金仓时搞不明白的地方。我们原来的员工表、部门表都用数据库层面自增主键，换到金仓后需要把主键生成机制统一改成序列。大致逻辑是：先创建一个序列，比如create sequence seq_employee_id，然后把表字段的默认值指向nextval('seq_employee_id')。好在金仓提供了一些兼容写法，为了省事我们部分表也利用了兼容模式下的行为，但重要的主表我还是坚持显式建序列，逻辑清楚，排查问题时不费劲。

存储过程迁移是另一个容易让团队烦躁的模块。HR系统里经常有跑批存储过程，比如月底考勤汇总、薪酬模拟计算，里面的逻辑很长，常见的有游标循环、异常处理、中间表数据清理。金仓的存储过程风格建立在类PL/pgSQL体系上，跟原来的PL/SQL并不是100%一致。

我们踩过的一个典型坑是异常处理。原来代码里习惯写exception when others then ...这种兜底捕获，金仓里的语法和系统变量名可能不一样，编译阶段不留心就会有各种报错。我的建议是：不要试图把每一个存储过程都原封不动搬过来，评估价值不高的，直接改写成Java定时任务；确实需要留在数据库里的，在测试环境反复编译验证，并且把日志表写入逻辑也兼容进去。

另外，触发器也要特别小心。人力资源系统里有些字段的“自动更新时间”是用触发器维护的，迁移后一定要逐个业务场景验证触发器的执行次数和执行结果。我那次就遇到过触发器本身编译成功，但触发时更新了错误列的情况，靠业务功能测试才暴露出来。所以不要只看编译是否通过，一定要做基于场景的行为验证。

3.4 字符集、大小写与保留字这几个隐形坑

这类问题往往藏得很深，但在测试时又会集中爆发。首先要说的是字符集。中文系统默认要选UTF8，这个基本不会错。但我们遇到过导入的旧数据里混了一些历史遗留的特殊字符，在导数据阶段就出现乱码，排查了半天才发现是客户端连接的编码设置问题。建议在迁移前进行一次数据体检，专门找出含异常字符的记录，提前处理，不要拖到割接窗口。

其次是大小写规则。原来的数据库里，不带双引号的标识符大多会被统一处理，而金仓对未加引号的小写标识符通常会转成大写存储，未加引号的大写标识符也按大写处理。这个东西听起来很简单，但实际开发中，很多人都写过select "user_name" from t_user，如果你把user_name用双引号括起来，那这个字段名的大小写必须跟库里的真实存储完全一致，否则就会报“列不存在”。我们当时的约定是全项目统一使用小写驼峰不加引号的写法，避免这种大小写不匹配问题。

再次是要避开保留字。user、key、size、order这类词，在金仓的不同兼容模式下可能都是保留字或受限词。HR系统表里常见字段名remark问题不大，但如果你有字段叫comment，那就要小心了。与其到处写转义，不如迁移前统一改字段名。

4. 数据迁移与应用适配的完整实操过程

4.1 迁移前环境准备和数据库初始化

这一节我要给你一条可以直接抄作业的实操路径。先说明一下，我们下面的命令和参数面向金仓V8系列，版本差异可能导致个别参数名称不同，你实际操作时先对照自己的环境验证。

第一步，准备一台符合信创要求的服务器，操作系统我们用的是国产化Linux发行版。下载金仓的安装包之后，解压并执行安装脚本，安装过程注意选择数据目录和初始化参数。

安装完成后，默认服务端口是54321，不是常见的5432。很多第一次用金仓的同事都会下意识用5432去连，然后报连接超时，找了半天才发现是端口问题。记住，金仓默认端口是54321。

第二步，创建业务数据库和业务账号。一般不建议直接用系统管理员账号跑业务，而是单独建一个hr_app用户，并创建一个独立的database，比如hrdb。命令大致如下：

注意这里的兼容模式，如果要选择Oracle兼容模式，通常在初始化或建库时通过参数控制。不同的V8小版本，界面和命令略有差异，你可以在官方文档里确认一下创建数据库时的兼容性选项。

第三步，给业务账号授权。如果这个账号是数据库所有者，通常自动拥有库内对象的全部权限；但如果你用单独账号只读访问，记得授权select权限给相关的表和视图。

4.2 结构迁移与数据导出的执行记录

金仓自带数据迁移工具KDTS，这套工具的思路就是通过连接源库和目标库来完成对象结构转换与数据搬迁。操作上基本是：新建迁移任务，填上源库的连接信息，再填上金仓的连接信息，选择要迁移的库或模式，勾选结构对象类型（表、序列、视图、函数、存储过程等等），点击开始，等待执行报告。

第一遍跑迁移任务，基本都会有一堆报错。不要慌，这些都是正常的。迁移工具的主要价值在于帮你把90%的常规对象给带过来，剩下的10%需要手工处理。我们的流程是：跑完一轮迁移，立刻登录金仓去数表和序列是否齐全，再抽几张表的字段类型核对，最后再跑数据一致性脚本。

如果是手工迁移场景，比如没有工具支持或者数据量特别大，我给你一个推荐的做法：源库按表分批导出为标准SQL或CSV文件，目标库按转换规则建好表结构，数据文件通过COPY命令或导入工具批量入库。这时候要注意分批提交，每导入一批做一个记录点，这样中间失败了不用从头再来。

4.3 Java应用侧改造：驱动、连接池与ORM配置

数据库层面搞定后，应用代码的改造就提上日程了。人力资源系统的应用是标准的Java技术栈，改造内容集中在三层：JDBC驱动、连接池、ORM配置。

先替换驱动，把原来的数据库驱动依赖替换成金仓的JDBC驱动jar包，典型的主类名是com.kingbase8.Driver，连接URL前缀是jdbc:kingbase8://。例如：

然后初始化连接池。我们用的Druid，改配置的时候发现几个地方需要特别注意。第一，驱动类名要换，否则连接池初始化失败。第二，连接池的探活SQL，也就是validationQuery，要改成金仓能接受的写法，比如select 1。第三，可以适当调整连接池大小。人力资源系统并发量不大，最大活跃连接数设到50就够用了，不需要为了“显得专业”把它调得很大。

如果你用的是MyBatis，SQL改动基本集中在自治SQL那一层，用上面提到的SQL方言改法处理即可，框架本身对数据库切换的适配比较平滑。如果项目用的是JPA或Hibernate，要特别关注方言配置。Hibernate的方言类需要切换成适配金仓的方言类，否则自动生成的SQL还会沿用老数据库的语法。我们当时特意做了验证：在所有老的方言配置清掉之前，只要有一处漏配，启动阶段就会看到生成SQL中带着老库的方言痕迹。

4.4 全流程验证：从功能回归到性能压测，再到割接回滚

到了功能验证阶段，我建议不要只满足于“页面能打开”。人力资源系统的业务闭环，每个都必须端到端跑通。我们当时设计了一张覆盖核心链路的验证清单，包括：新员工入职建档、调动转岗、离职流程、请假和加班审批、月度考勤汇总、薪酬试算与发放、绩效考核结果导入、各类统计报表导出。

这里有一个经验值得单独讲：薪酬和考勤计算往往是事务重灾区，动不动就要把几千条计算明细在一个大事务里提交。这类批处理场景在迁移后很容易遇到性能劣化，建议代码层面做分批提交，比如每500条提交一次，而不是一个循环全做完。我们就是靠着这个改动，把薪酬计算时间从改造初期的十几分钟降回了原来的水平。

性能压测方面，不要只测接口平均响应时间，还要关心数据库端的慢SQL。金仓同样有执行计划查看手段，分析思路跟主流数据库大同小异。我们把压测期间记录下来的慢SQL拿出来，一条条用执行计划分析，发现有两类问题最常见：一类是原来索引没有跟着迁移过来，另一类是统计信息没有收集，优化器选择了错误的Join方式。解决方案很简单，执行ANALYZE收集统计信息，再给大表相关条件补上缺失的索引。

割接方案要提前设计好，核心原则就是可回滚。我们当时的做法是：割接窗口开始后，先停应用，再把旧库的写入停掉，用最后一次增量同步脚本把差异数据补到金仓，最后启动新应用，连接新库。同时保留旧库的只读备份，如果新系统出现短期内无法解决的重大问题，立即切换回旧库。这个回滚开关一定要提前演练一次，别到真出了故障再手忙脚乱。

5. 常见问题与排查技巧实录

5.1 连接、驱动和权限问题的速查

连接类问题占了我们整个迁移周期故障的一大半，而且很多都特别基础。

最常见的就是端口写错，默认用了5432而不是54321。解决办法是检查ss -lntp里金仓进程的监听端口，确认后统一修改连接配置。

第二个常见问题是驱动版本过旧。如果你从老项目里随便捞一个金仓驱动jar，连新版本数据可能会报协议不兼容或者找不到类。这个没什么好说的，去官方网站下载跟数据库版本配套的最新驱动。

第三个问题是权限不足。应用账号能登录，但执行查询时报“permission denied for table xxx”。这个往往是迁移工具建了表，但表的所有者不是hr_app，或者没有授予相应的权限。可以用ALTER TABLE ... OWNER TO hr_app把表所有权归拢过来，或者在建模时直接将序列、表的所有者都指定为业务账号，干净利落。

还有权限问题是初始化脚本里创建的扩展，比如一些兼容函数依赖的扩展，需要数据库超级权限才能安装。如果建库后没有完整执行初始化脚本，业务SQL就会报“函数不存在”。这类问题不好一眼看出来，排查时多看一眼初始化日志。

5.2 语法兼容报错的定位方法

开发经常跑来问：“为什么一样的SQL在原来数据库能跑，在这里就报语法错误？”碰到这种情况，最快的定位办法是打开数据库日志，找到出错SQL的原文，再看具体报错位置。通常问题就集中在几个地方。

• 关键字冲突：order、user、size、key这类词如果恰好做了字段名，裸写会报错，需要用双引号括住，或者干脆改字段名。
• 分页写法：原库的limit offset写法在Oracle兼容模式下需要替换。
• 自连接更新：就是前面提到的update a join b这类语法，在Oracle兼容模式下不支持，需要拆解。
• 数据库函数名差异：比如months_between在Oracle兼容模式下可用，但如果你原来用的是MySQL风格的datediff，那对应函数要改写。

我建议项目组维护一份“SQL方言对照表”，每次遇到一个新问题就记录一条，后面新同事上手就能快速避开这些坑。这份对照表我到现在还留着，换个项目同样适用。

5.3 性能劣化和统计信息问题

迁移之后性能变差，绝大多数情况下不是数据库本身不行，而是“环境变了”。一个典型场景就是统计信息没收集，优化器拿不到准确的表行数，然后选了嵌套循环连接而不是排序合并连接，大表查询瞬间就慢了。解决办法是跑一轮ANALYZE，之后如果还慢，再打开执行计划逐步看。

另一个常见现象是索引缺失。迁移工具迁移结构时，如果只转表结构而漏掉索引，那么高频查询条件就扫描全表。我们当时就发现考勤明细表是千万级数据量，漏了一个索引，按员工编号查询时慢得没法用。所以结构迁移完成后，一定要对照源库的索引清单逐项核验，不要相信工具默认执行的结果。

还有一类问题是数据类型隐式转换。比如字段是varchar，你在SQL里传了整型值，驱动和数据库都做了隐式转换，索引就可能失效。解决办法是写SQL时显式转换类型，尽量保持字段类型和绑定参数类型一致。

5.4 数据不一致和乱码的定位

数据迁移完成不等于万事大吉，一致性校验是必须动作。我们的校验思路分三层：

• 总数校验：每张表用count(*)对比源库和目标库的行数，快而且能框出大方向问题。
• 关键字段抽样校验：对员工编号、薪资、部门ID这类关键字段做全部抽样或按比例抽样，分别求出sum、min、max来比较。
• 业务明细抽验：从业务报表里挑几个真实案例，比如某个月的薪酬发放单，逐条比对字段值。

乱码问题大多出在导入链路。如果发现乱码，优先确认源库字符集、导出文件编码、导入工具客户端编码这三者是否一致。我们当时最省心的方案是统一约定为UTF8，并且让数据迁移工具尽可能直连源库读取，减少中间文件转换环节。

说实话，国产数据库迁移这件事，干之前觉得是“换一个数据库”，干完之后才发现其实是“用一套方法论把一个旧系统翻新了一遍”。人力资源系统本身并没有太多高深技术，但正因为它是真实业务系统，才逼着我们把每一条SQL、每一个表、每一个批处理逻辑都认认真真检查了一遍。这个过程中积累下的那本“SQL方言对照表”和那套可回滚割接流程，反而是比“上了金仓数据库”本身更大的收获。

如果你也在准备做类似的信创适配，我最想说的就是：兼容性不能靠想象，工具能帮你省力，但不能替你验证。每一步都要在测试环境里跑出真实结果，老老实实把数据核对清楚。另外，一定记得给自己留好退路，旧库的备份和回滚方案别等到割接当天才想。毕竟数据库就像地基，地基换完了，楼还要继续住人的。