这事儿得从半个月前说起。我们公司那套老系统，MySQL跑了好几年，数据量从最初的几百兆飙到快2 TB，表结构也改了好几轮。最近业务部门天天抱怨查询慢，运维那边盯着磁盘空间直叹气——分区快满了，再这么下去就得停机扩容。领导一拍桌子：迁移吧，趁周末搞。于是，我成了这个迁移项目的“总指挥”，从规划到落地，踩的坑一个比一个深，今天就跟大伙儿唠唠这其中的门道。
迁移的第一步，不是动手敲命令，而是坐下来画张图。你得先搞清楚：老库在哪儿、新库在哪儿、数据量多大、网络带宽够不够、业务能停多久。我们当时选了阿里云的 RDS 做新家，因为公司服务器在本地机房，中间隔着公网。别看 2 TB 好像不大，按 100 M 带宽算，理论传输速度也就 12 MB/s，实际上还得打折——因为 MySQL 的 dump 文件是文本格式，压缩后体积能缩到 1/3，但网络抖动、丢包重传都会拖慢进度。我们实测下来，纯传输就得 10 小时，加上数据校验、索引重建、业务验证，周末两天根本不够。后来改成走 VPN 专线，带宽提升到 500 M，这才勉强压到 6 小时内完成全量迁移。
数据迁移最怕什么？不是慢，是丢。我们试过两种方案：一是用 mysqldump 导出全量 SQL，然后在新库导入。这法子简单粗暴，但 2 TB 的 SQL 文件光生成就得 4 小时，导入时还可能遇到字符集问题。我亲眼见过同事因为没加 参数，导致 emoji 表情全变成乱码。二是用 Percona XtraBackup 做物理备份，直接拷贝数据文件到新库，速度快了不止一倍。但物理备份有个致命缺陷——新旧库的 MySQL 版本必须一致，否则数据文件格式不兼容。我们老库是 5.7，新库是 8.0，中间差了三个大版本，只能老老实实用逻辑备份。
逻辑备份还有个坑：大事务。老库里有张日志表，每天写入量上千万，导出时如果不加 ，会锁住整张表，线上业务直接卡死。我们加了参数后，导出过程倒是顺了，但导入时又出了幺蛾子——新库的 设得太小，大事务提交时日志写满，报错 “Log sequence number too high”。调成 2 GB 才搞定。迁移不只是复制粘贴，还得把两边的配置参数对齐，尤其是 、 这些跟内存、包大小相关的，差一点就报错。
全量迁移做完，只是万里长征的第一步。最头疼的是增量同步——老库还在跑业务，新库必须追上这些变化。我们试了阿里云 DTS 服务，配置简单，但有个坑：如果老库的 binlog 格式不是 ROW，DTS 会拒绝同步。老库之前为了性能设成 MIXED，改了之后又发现 binlog 的保留天数太短，只有 3 天。要是迁移过程中断超过 3 天，增量数据就找不回来了。只能提前一周把 binlog 保留时间调到 14 天，并每天检查磁盘空间。同步过程中，我们还遇到主键冲突——老库有张表是自增主键，新库导入时忘了重置自增起始值，导致两边数据插入时撞车。解决方案是同步前先删除新库的自增主键，同步完再重建。
业务验证阶段，我们犯了一个低级错误。迁移完成后，开发团队在新库上跑了半小时查询，发现响应时间从老库的 3 秒降到 0.5 秒，大家正高兴呢，突然有同事喊：“用户登录报错了！”一查，原来是老库的存储过程里用了 ，迁移后新库的序列号没对齐，导致插入关联表时 ID 错位。更离谱的是，有个定时任务依赖老库的 Event Scheduler，迁移时忘了在新库上重建，任务直接停跑了两天，积压了一批数据。从那以后，我们定了个规矩：迁移清单必须包括所有存储过程、触发器、事件、用户权限，一个都不能少。
回滚预案是一道保险。我们准备了三套方案：A 计划是如果增量同步失败，直接切回老库，损失几小时数据；B 计划是如果全量迁移过程中网络断了，用 增量传输数据文件；C 计划是如果新库性能不如预期，用 在线改表结构。结果都没用上，但心里踏实。最悬的一次是凌晨 2 点，增量同步突然报错 “Binlog 坐标不一致”，我们连夜查日志，发现是老库的主从切换导致 binlog 文件名变了，DTS 没反应过来。好在监控脚本提前告警，手动修正坐标后恢复。要是没有这套预案，那天晚上估计得通宵修数据。
迁移完成后，我们做了两件事：一是持续监控一周，查看慢查询、死锁、连接数有没有异常；二是把迁移过程中踩的坑写成文档，包括每个报错的截图、修复命令、耗时统计。后来公司另一个团队做数据迁移，直接拿我们的文档当模板，只改了 IP 地址和端口号。最让我感慨的是，迁移完三个月后，新库的磁盘使用率又冲到了 80%。为什么？因为老库的归档策略没搬过来，历史数据全堆在新库里。你看，数据迁移从来不是一次性动作，它是业务迭代的一部分。如果只盯着“把数据搬过去”，而不考虑后续的治理和优化，那只是换个地方继续烂摊子罢了。
