我见过太多团队在数据库迁移上栽跟头。明明是一次常规操作，结果不是丢数据就是服务中断几个小时，变成全员加班救火。其实MySQL迁移这件事，说难也难，说简单也简单，关键看你有没有一套靠谱的方法论。今天这篇就聊聊我这些年总结出来的实战经验，从备份到切换，每一步该怎么走，哪些坑必须避开，一次性给你讲透。
先说备份。很多人觉得mysqldump就是万能钥匙，一个命令下去万事大吉。但实际生产环境里，数据量一旦上了百G级别，mysqldump那种逻辑备份的方式就有点力不从心了，备份时间长不说，恢复起来更是折磨人。这时候物理备份才是正解，像Percona XtraBackup这种工具，直接复制数据文件，备份速度能快上好几倍。我见过一个电商团队，库里有800多G数据，用mysqldump跑了快十个小时，换成XtraBackup后四十分钟搞定。而且物理备份还有个好处，恢复的时候直接替换数据目录就行，不用一条条执行SQL，省下的时间够你喝好几杯咖啡了。
备份做完，接着就是迁移策略的选择。这里有个关键分岔路：你是要停机迁移还是在线迁移？如果业务允许你半夜停两三个小时，那简单粗暴的停机迁移就够了，先把备份恢复到新库，然后停掉旧库的写入，把那点增量数据同步过去，改个连接串就完事。但如果你面对的是7x24小时不能停的服务，那就得上主从复制这套玩法了。先在旧库上配置binlog，然后让新库作为从库去追旧库的binlog，等两个库的数据追平了，再做一个秒级的切换。这套流程我建议每个DBA都在测试环境演练几遍，因为真正的切换瞬间其实压力巨大，手一抖就可能出问题。
说到binlog，很多人忽略了一个细节：binlog_format到底该用ROW还是STATEMENT？我强烈建议用ROW模式。STATEMENT模式记录的是SQL语句本身，看起来挺省空间，但遇到NOW()、UUID()这种非确定性函数，主从之间数据就容易对不上。我有一次就踩过这个坑，一个统计报表功能从迁移后数字就对不上，排查了半天才发现是binlog模式的问题。ROW模式虽然日志文件会大一些，但它记录的是每一行数据的具体变化，主从复制的一致性有保障，这点存储开销完全值得。
数据同步这块，不少人会想到用一些现成的同步工具，比如Maxwell、Canal之类的。这些工具确实能把binlog解析成JSON格式，方便你做一些数据转换或者同步到其他系统。但要注意，这些工具本身也是要读取binlog的，如果你同时开了好几个同步任务，binlog的保留时间就得相应调长，否则容易追不上。另外，这些工具如果配置不当，可能会漏掉一些DDL操作，导致表结构不一致。所以我的建议是，核心业务的数据同步还是走官方的主从复制，第三方工具只用来做辅助的同步需求。
接下来是验证阶段，这一步千万不能省。数据都同步过去了，新库看着也正常，但你真的敢直接切流量吗？我见过有人迁移完就急着切，结果第二天发现有些存储过程、触发器没同步过去，业务逻辑直接崩了。验证的时候，除了对比两张表的数据量、checksum之外，还得检查存储过程、函数、触发器、事件调度器这些，一个都不能漏。另外，新库的字符集、排序规则也要跟旧库保持一致，不然中文数据可能会变成一堆乱码。最稳妥的做法是写个脚本，自动对比两边的表结构、索引、权限，有差异就报警，省得你一条条去看。
切换这一步，很多人容易犯一个毛病：直接改应用的数据库连接配置。但如果你用的是云数据库，或者有独立的数据库中间层，其实有更平滑的方式。比如你可以先在数据库层做读写分离，让一部分读流量先切到新库上，观察一段时间没问题了，再把写流量也切过去。这种灰度切换的方式，即使新库有问题，影响面也是可控的。我见过一个金融团队，他们甚至把切换时间选在凌晨三四点，还做好了回滚预案，一旦新库出现性能问题，五分钟内就能切回旧库。这种敬畏之心，才是迁移成功的保障。
再说说回滚预案。很多人觉得都迁移成功了，回滚预案就没用了。但你要知道，数据库迁移这事，切换成功只是开始，后面几天才是真正的观察期。业务高峰期的时候，新库的慢查询有没有变多？连接数够不够？磁盘IO是不是成了瓶颈？这些问题可能要跑几天才能暴露出来。所以旧库先别急着销毁，保留个两三天，万一新库出问题，你还能快速回滚。我建议你在迁移完成后，至少监控一周的性能指标，包括QPS、慢查询数量、锁等待时间这些，跟旧库的历史数据做个对比，心里才有底。
数据库迁移这事，说穿了就是一场有准备的战役。备份、同步、验证、切换、回滚，每一步都有章可循，关键是你有没有把这些细节落到实处。很多人失败不是因为技术不行，而是因为轻视了流程。毕竟，数据库不出事的时候，你感觉不到它的存在；一旦出事，那就是全公司最头疼的事。做好准备，才能让迁移这件事变得波澜不惊。
