说实话，每次接到数据库迁移的活儿，我心里都先打个突。不是技术有多难，而是这活儿容错率太低，一个不小心，线上业务就得跟着遭殃。前阵子帮朋友公司做了一次MySQL从阿里云迁到自建机房的全程操作，踩了不少坑，也攒了些经验。今天就把这套从备份到验证的完整流程掰开揉碎了讲给你听，全是实打实的干货，能帮你少走几公里弯路。
先说备份这步，很多人觉得mysqldump一把梭就完事了，但这里面水很深。你得确认数据库引擎，如果是MyISAM，直接锁表备份没问题；但如果是InnoDB，一定要加上参数，这样才能在不锁表的情况下拿到一致性快照。我见过太多人忽略这个参数，结果备份出来的数据在恢复时出现主键冲突，那叫一个头大。还有，备份文件别只存一份，至少本地留一份、异地再传一份，万一服务器硬盘挂了，你还能有个救命的副本。另外，备份前先执行一下，把缓存里的数据都刷到磁盘上，确保备份文件里包含的是最新状态，这个细节很多人会漏掉。
备份完了，很多人急着开始导入，这里又是个大坑。恢复前一定要先检查目标服务器的MySQL版本，版本跨度太大，比如从5.6导到8.0，那SQL语法兼容性问题能让你怀疑人生。建议先在测试环境把备份文件恢复一遍，看看有没有报错，特别是字符集和排序规则，utf8mb4和utf8之间转换，很容易出现乱码。我那次迁移就栽在这儿，源库用的utf8mb4unicodeci，目标库默认是utf8mb4generalci，恢复完一看中文全变问号，吓得我赶紧重新调整配置。所以恢复前，先确认目标库的和设置，最好在配置文件里显式写清楚。
接下来就是导入环节，这里有个性能优化的技巧。如果你直接用导入，那速度慢得能让你等到花儿都谢了。建议先把binlog关掉，因为导入过程中产生的binlog会严重拖慢速度，等导入完再开启就行。命令是，导入完再设回来。另外，如果备份文件特别大，超过几个G，建议用命令分段导入，或者直接用工具，效率能提升好几倍。还有个小细节，导入前临时把改成0，改成0，导入完再改回来，这样能减少磁盘IO压力，速度至少快一倍。
导入完成后，别急着切流量，先做数据一致性校验。很多人觉得导入没报错就万事大吉，其实不然。我通常会用命令，在源库和目标库分别执行，对比两张表的checksum值是否一致。如果表特别多，可以写个脚本循环执行，把结果输出到文件里统一比较。另外，随机抽几条关键业务数据，比如最近一周的订单记录、用户表里最新注册的几个人，对比一下字段值是否完全一致。我那次迁移就发现，有个表的自增主键在导入后重新排序了，虽然数据没丢，但业务逻辑会乱，只能重新调整。
数据校验通过后，还有个容易忽略的点——视图、存储过程、触发器这些数据库对象。mysqldump默认会包含这些，但如果你用了参数跳过某些表，那这些对象可能就不完整了。恢复后一定要检查一下，用和命令看看数量是否和源库一致。我那次就漏了一个定时触发器，导致第二天凌晨该执行的任务没跑，幸好及时发现，不然数据就全乱了。建议在备份时用参数显式包含这些对象，恢复后再逐一核实。
整个迁移过程中，最考验心态的就是业务切换那一刻。我建议先做一次完整的预演，在一个独立环境里，用最新的备份文件走一遍全部流程，记录好每一步耗时。预演通过后，再安排正式的切换窗口。正式操作时，先停掉写入业务，把源库改成只读，然后做一次增量备份（用抓取binlog），接着恢复增量数据到目标库，才切换连接。这里有个小技巧，可以先把源库的只读账号给应用用，这样即使切换失败，还能快速回滚，不至于让业务长时间中断。
再啰嗦一句，迁移完别急着删除源库数据，至少保留一周作为保险。同时，把目标库的监控和告警配置好，特别是磁盘空间、连接数、慢查询这几个指标，确保新环境稳定运行一段时间后再做清理。数据库迁移这事儿，做得多了你会发现，真正难的不是技术操作，而是每个环节的细心和预案。记住，每一步都验证，每一处都留退路，这才是迁移的正确打开方式。
