数据库迁移实战：如何实现从Oracle/MySQL到国产库的平滑无感切换

这两年我接触过不少从Oracle、MySQL迁移到国产数据库的团队，最深的感受是：多数人以为最大的风险在“数据搬得慢”或者“工具不好用”，做到一半才反应过来，真正的难关是应用层的那些隐晦SQL、字符集差异、账号权限，甚至是某个上游Job在半夜三点的自动重连逻辑。

这次技术访谈的对象是一位做过多次核心业务“国产化改造切换”的资深工程师。我们聊了全程，话题集中在最容易被问、也最容易被误解的那句——“如何让用户平滑无感迁移”。以下内容是我把他多年的实践拆成可落地方案后的整理，不是厂商宣传稿，也不会告诉你“换了这个数据库就万事大吉”，只讲真实踩过、也真正解决的细节。

1. 先理解“无感迁移”到底要满足什么，否则后面全部白做

1.1 业务侧“无感”不等于代码零改动

很多刚立项的团队会犯一个认知错误：以为“无感”就是让应用什么都不改，把数据导过去、改个JDBC连接串就算完事。

实际项目里几乎不可能做到完全零改造。为什么？因为每一种数据库的SQL方言、内置函数、事务行为、字符串比较规则都不一样。比如：

• Oracle的VARCHAR2(4000)在UTF-8下实际占用空间按字节算，国产数据库里可能默认按字符算，字段长度含义不同，应用写入超长数据时行为就不同。
• Oracle里ROWNUM分页写法和MySQL的LIMIT不同，一套代码如果同时兼容这两种数据库，SQL必然要做方言适配。
• Oracle对空字符串和NULL不加区分，而多数MySQL生态习惯里空字符串是空字符串，NULL是NULL，一旦程序里有where name = ''这类写法，数据校验阶段很可能出现不一致。

所以“无感”真正的含义，是把用户和业务感知到的变化压缩到最小：界面不变、接口不变、调用习惯不变、读取到的数据一致性不变，而底层数据库从Oracle/MySQL切到国产数据库，应用只做局部适配，不需要推倒重写。

1.2 四个维度衡量平滑度

从实际操作来看，衡量一次迁移是否“平滑”，需要同时看四个方面：

• 停机窗口：切换期间业务最多能接受停多久。很多系统白天不能停，只能选凌晨或者双休日低峰段。有的核心系统要求毫秒级切换，那就意味着不仅是停机窗口短，还要做好双写和灰度切换。
• 数据一致性：全量数据搬迁后，源库和目标库的数据必须逐行可比，不能只比对总数。增量同步也在持续进行，任何一条记录不一致都有可能在后续业务中放大。
• 应用改动面：有多少SQL需要改？多少存储过程、序列、触发器和任务要翻译？这个改动量直接决定项目周期和上线后回归测试的力度。
• 回切风险：如果切换后国产数据库侧出现严重问题，应该怎么办？是无条件回切，还是保留一部分流量继续观察？回切场景下的反向同步链路是否提前测过？

这四个维度里，第一个和第三个容易被写进合同，第二个常常被认为“反正数据导过去就对了”，第四个往往在项目快结束时才被想起来。

1.3 容易被忽略的隐性指标

除了停机时间和数据一致性，还有几个不起眼但常在验收阶段闹脾气的点。

• 数据库账号权限结构：很多老系统创建了一堆账号，分不清哪个业务在用。迁移到国产库后如果把所有账号合并成一个超级用户，安全合规过不了；如果按原样复制，很可能漏掉对某个定时任务的授权。
• 隐式类型转换：Oracle中to_date写法和MySQL的str_to_date不同，有些国产数据库同时兼容两种，但前提是设置对了兼容参数。这个参数一旦默认值不对，迁移完大量SQL会报“函数不存在”。
• 分布式环境的全局事务：原来用的是Oracle RAC，应用依赖全局事务；迁移到某些国产分布式数据库后，如果事务跨节点，可能需要应用调整事务边界或引入分布式事务方案，这是比SQL改造更难处理的部分。

我在访谈中反复问对方：“你们怎么判断一次迁移算成功？”他的回答是：“成功不是切换完成那一个瞬间，而是新库稳定跑过完整业务周期，包括月末结账、月初报表、批量任务、高峰期并发，一个都不能少。”

2. 迁移前做完这轮评估，能避开一大半返工

2.1 对象兼容性摸底不能只查表

准备迁移前，先用脚本把所有业务相关对象完整抽出来，千万不要只迁移表，再手工补其他对象。现实项目里至少要整理出以下清单：

• 表结构、字段类型、默认值、注释
• 主键、唯一约束、外键、检查约束
• 普通索引、唯一索引、函数索引、位图索引
• 序列、视图、物化视图、同义词
• 存储过程、函数、包、触发器
• 定时任务、调度器作业
• 数据库链接、外部表
• 用户、角色、对象权限、系统权限

单是这份清单做完，很多人就会发现老系统里存在大量“历史遗留欠账”：某个触发器其实已经失效，但没人清理；某个外部表对应的文件路径已经不存在；某个同义词引用的对象在源库中已删。