上周和一个创业的朋友吃饭，他愁眉苦脸地跟我说，公司系统最近卡得不行，用户一多就像老牛拉车。我说：“你们是不是该换数据库了？”他愣了一下，问：“数据库还能换？换完数据怎么办？”这不，正好撞上我今天要聊的话题——数据库迁移。
说白了，数据库迁移就是把数据从一个地方搬到另一个地方。听起来像搬家，实际操作比搬家还烦。搬家顶多是箱子、家具、锅碗瓢盆，搬完重新摆一摆就行。数据库迁移呢？你得保证数据不丢、格式不乱、业务不停，服务器那头还一直有人往里写数据。这就像搬家的时候，家里还在不断添新东西，你得一边打包一边收快递，还得保证快递小哥能找到新地址。
常见的迁移场景有好几种。第一种是升级，比如从 MySQL 5.7 换到 MySQL 8.0，版本变了，但底层还是同一套东西。这相对简单，主要注意兼容性——新版本可能砍掉了一些老功能，你的代码里还在用，就得改。第二种是换厂商，比如从自建的 PostgreSQL 搬到云上的 RDS，或者从阿里云搬到腾讯云。这种要处理连接方式、权限管理、备份策略的差异，牵一发动全身。第三种最狠——换数据库类型，比如从关系型的 MySQL 换成文档型的 MongoDB。这就像把中文小说翻译成英文，还得保留原著的意境和节奏，数据结构、查询方式、索引策略全得重新设计。
很多人以为迁移就是导出导入。把 SQL 文件导出来，再跑一遍建表语句和插入语句，似乎就搞定了。可是现实是，生产环境的数据量动不动就几百 GB 甚至几 TB，导出的 SQL 文件打开都费劲。更别提迁移过程中，业务系统还在持续写入新数据——你导出的那一刻是 1 点整，等导入完成已经 2 点半了，这一个半小时的新数据全丢了。所以正式的数据库迁移，至少要解决两个核心问题：数据一致性和停机时间最小化。
数据一致性怎么做？一般用快照。比如 MySQL 的 mysqldump 加上 参数，能在不锁表的情况下拿到一个一致性快照。RDS 等云服务也提供备份恢复功能，可以直接拿某个时间点的全量备份在新环境恢复。但快照只能解决迁移开始那一瞬间的数据状态，后续的增量数据还得靠同步机制补齐。这时就需要数据库的复制功能——主库写数据，从库同步，迁移过程中可以先切到新库，再把旧库的增量数据追过去。
停机时间的长短取决于业务容忍度。有些系统允许凌晨停机两小时，比如内部管理系统、报表平台。这种可以采用“先全量、再增量、切流量”的方案：先导全量数据到新库，然后持续同步增量数据，等两边数据追平后宣布停机，改连接串，重启服务，几分钟搞定。但如果是电商、支付、社交这类 7×24 小时在线的系统，停机每一秒都是真金白银。这时就得用“双写”策略——应用层同时往新旧两个库写数据，等确认新库跑稳了，再逐步把读流量切过去，停掉旧库。听上去很美好，实际实现却坑多：两边写入顺序不一致怎么办？某个字段在新库里不支持怎么办？双写过程中出现异常怎么回滚？每个问题都可能让你加班到凌晨三点。
举个例子，我之前参与过一个项目，要把 Oracle 迁移到 MySQL。Oracle 有序列、触发器、存储过程这些“高级功能”，而 MySQL 要么没有，要么实现方式不同。序列得改成自增主键加业务主键的组合，触发器得用应用层逻辑替代，存储过程得拆成多个 SQL 语句封装在代码里。光梳理这些依赖关系，就花了整整两周。更头疼的是，Oracle 的 SQL 语法和 MySQL 有差异，比如分页查询——Oracle 用 ，MySQL 用 。看似小问题，但业务系统里写了几百条这种 SQL，每一条都得手动改。改完后还要跑全量回归测试，确保每个查询结果和原来一模一样。
迁移过程中还有个容易忽视的坑——字符集和排序规则。比如旧库用的是 GBK 编码，新库设成了 utf8mb4。utf8mb4 更包容，能存 emoji，但 GBK 里的某些字符在 utf8mb4 下可能被错误映射。导数据时不会报错，却会导致用户查询出来的内容出现乱码。这种问题最烦人，因为测试环境数据量小，不容易暴露；一上生产、数据量大了、用户使用时才会冒出来。所以迁移前一定要做字符集映射验证，最好拿生产数据的一个子集做全流程演练。
还有一种更隐蔽的坑——数据类型精度差异。比如 MySQL 的 支持到秒，而 PostgreSQL 的 支持到微秒。迁移时如果直接把字符串转过去，精度不会丢。但反过来，从 PostgreSQL 迁到 MySQL，微秒部分就会被截断。如果业务涉及高频交易、日志排序等对时间精度敏感的场景，这种截断会导致数据错位。类似的问题也出现在浮点数上——MySQL 的 是 4 字节，PostgreSQL 的 是 8 字节，精度相差甚远。数据量小的时候看不出，一跑统计报表，数字就对不上了。
再说一个我亲眼见过的案例。某公司把自建 MySQL 迁到云 RDS。开发团队按手册一步步操作，全量迁移成功，增量同步也跑起来了。但正式切换那天，他们发现新库的写入延迟一直在增加，从几秒变成几分钟，甚至几十分钟。一查原因，是云 RDS 的 IOPS 上限设得太低，业务高峰期的写入量超过了限制，导致同步线程被卡住。更惨的是，他们没有准备回滚预案——旧库的连接串已经改了，新库又扛不住，只能临时扩容 IOPS，业务中断了将近一个小时。从那以后，我每次制定迁移方案，都会强制要求加一条：必须准备回滚方案，并且演练至少一次。
回到开头那个朋友的问题。我给他的建议是：先别急着动手。花一周时间梳理现有数据库的依赖关系——哪些表被哪些服务读写、有没有触发器或存储过程、数据量大概多少、业务高峰在什么时段。然后选一个业务低峰期，做一次小范围演练，比如先迁一个非核心模块。等验证没问题后，再规划全量迁移的时间窗口。迁移当天，准备好回滚脚本，盯着监控面板，一旦新库的延迟或错误率异常，立刻切回旧库。别怕折腾，数据库迁移这事儿，慢就是快，稳就是省。
