这事儿说起来挺有意思的。搞数据库迁移，听着像是个大工程，可真正干过的人都知道，多数时候就是几个命令的事儿。但偏偏就有不少人栽在这上面，数据丢了、服务挂了、业务停了，哭都来不及。我见过太多人把简单的迁移搞复杂了，也见过不少人把复杂的迁移想简单了。今天就跟大家聊聊MySQL数据库迁移这件事，我踩过的坑、用过的招，一股脑儿都倒出来。
先说说最基础的逻辑迁移。很多人一上来就问用什么工具好，其实你得先搞清楚迁什么。是整库搬迁，还是只迁几张表？是同版本迁移，还是跨版本升级？是测试环境到生产环境，还是不同机房之间？这些条件不一样，打法就完全不一样。比如同版本迁移，用mysqldump导出再导入，基本够用。但如果你是从MySQL 5.6迁到8.0，那就要注意字符集、排序规则、SQL模式这些变化。我有个朋友就吃过这个亏，5.6的库直接dump到8.0，结果一堆存储过程跑不起来，因为8.0对GROUP BY的语法更严格了。所以迁移前的版本对比工作，宁可多花半小时，也别省那几分钟。
再说说工具选型。mysqldump是老牌工具了，优点是好用、稳定，有耐心都能学会。缺点也明显：慢，特别慢。一个几百G的库，dump出来十几个G的SQL文件，再往新库导入，跑个一天一夜是常事。而且mysqldump是单线程的，数据量一大，CPU和内存都闲着，就IO在那儿慢悠悠地转。这时候就得搬出物理备份工具，比如Percona XtraBackup。它是基于文件级别的备份，速度快得多，还能做增量备份。我去年帮一个电商客户迁移了1.2T的库，用XtraBackup全量备份花了3小时，再配合binlog增量同步，最终停机窗口控制在15分钟内。要是用mysqldump，估计得停机一整天。
不过工具再好，也得看你怎么用。我见过不少人，把mysqldump的参数堆得跟天书似的，结果导出文件里一堆乱码。其实核心参数就那么几个：--single-transaction对InnoDB表做一致性备份，不锁表；--quick直接输出到标准输出，避免内存溢出；--no-create-info只要数据不要表结构；--where加条件筛选数据。有个小技巧：如果你只需要迁移部分数据，别用where硬筛，效率太低了。先在新库建好表结构，然后用SELECT INTO OUTFILE导出CSV文件，再用LOAD DATA INFILE导入，速度能快好几倍。我试过，100万条数据，mysqldump导入要40分钟，LOAD DATA INFILE只要3分钟。
再说说迁移过程中的坑。最大的坑是字符集不一致。很多老系统用的latin1，新库默认utf8mb4，直接导进去，中文字符全变问号。解决方法是导出时指定字符集：--default-character-set=latin1，导入时再转成utf8mb4。还有个坑是外键约束。如果你有大量外键关联，直接导入会报错，因为表顺序不对。解决办法是先在导出时加上--skip-triggers --skip-foreign-checks，导入完再手动重建外键。不过说实话，我建议大表最好别用外键，业务层做校验更灵活，迁移起来也省心。
别忘了停机窗口这件事。很多业务要求零停机迁移，这就得用到主从复制了。先在源库开启binlog，然后在新库建立主从关系，等数据同步追平后，切写操作到新库。听起来不复杂，但坑也不少。比如主从库的server-id必须不同，binlog格式建议用ROW模式，不然遇到自增主键冲突就麻烦了。还有网络延迟，如果主库在新加坡，从库在北京，延迟可能几百毫秒，这时候切写操作要格外小心。我建议先做一次预切换，验证所有功能正常，再正式切。预切换时把写操作切到新库，运行半小时没问题，再切回来。这样正式切换时心里有底。
生产环境的迁移，最怕的就是数据一致性问题。你没法保证在迁移过程中没有新的写入。这时候就得用工具来校验了。pt-table-checksum是Percona Toolkit里的利器，可以逐行比较源库和新库的数据，发现不一致就输出报告。然后再用pt-table-sync进行修复。我有个客户在迁移后跑了三天才发现少了两万条订单记录，就是因为没有做校验。从那以后，我把数据校验写进了所有迁移方案的标准流程里。别嫌麻烦，数据这东西，丢了找回来比迁过去难一百倍。
说说备份这件事。迁移前一定要做全量备份，这是底线。很多人在迁移过程中发现新库出问题了，想回退，结果源库已经被改了，两边都废了。我建议迁移前先做一次全量冷备份，把数据库文件打包存到安全的地方。如果条件允许，再做一个逻辑备份，这样不管遇到什么问题，都有两条路可退。另外别忘了测试环境。别直接在生产库上练手，先在测试环境跑一遍完整流程，记录下每一步的耗时和异常。我每次迁移都会准备一个checklist，从环境检查、备份、导出、导入、校验、切写、监控，每一步都打勾确认。这样心里踏实，出了问题也知道在哪个环节。
说到底，数据库迁移这事儿，70%是技术，30%是管理。技术层面，工具选对、参数调好、流程规范，基本不会出大乱子。但管理层面，沟通协调、时间窗口、回退方案，这些往往比技术本身更考验人。我见过最成功的迁移，不是技术最强的团队做的，而是准备最充分的团队做的。他们会提前一个月做预研，提前一周做预演，提前一天做全量备份，然后在正式迁移那天，按部就班，该喝茶喝茶，该吃瓜吃瓜。真正的高手，不是把复杂的事情做得很帅，而是把复杂的事情做得很稳。
