干这行久了你就知道，MySQL 数据迁移这事儿，看着简单，翻车几率其实挺高。很多人以为不就是导出导入吗，结果数据量一大、字符集没对齐，或者业务还在跑着就动手，导致数据对不上、应用崩了，甚至连哭都来不及。今天我就掰开揉碎聊聊，从备份到最终切换，怎么把这活儿干得漂亮。
第一步，先搞清楚迁移的目标和场景。你是要把单机库搬到新服务器，还是在做读写分离的升级？是只换硬件不换版本，还是从 MySQL 5.7 直接跳到 8.0？这些差别大了去了。比如版本跨越太大，一些语法和默认字符集会变，导出的 SQL 直接在新库跑不动。我见过最坑的一次，有人把 5.6 的数据直接导入 8.0，结果 datetime 字段的默认值格式变了，整张表报错。所以动手前先做调研：源库的版本、引擎类型（InnoDB 还是 MyISAM）、数据大小、是否有主从复制、业务能接受的停机窗口多长。这些信息列个表，后续每一步都跟它挂钩。
备份这块千万别图省事。很多人直接用 mysqldump 一把梭，但如果库里有几百 GB 的 InnoDB 表，mysqldump 导出时会把整张表锁住，业务直接停摆。正确的做法是加上 --single-transaction 参数，开启事务级别的快照，这样导出过程中不会阻塞写入。但要注意，这个参数只对 InnoDB 有效，MyISAM 表仍会被锁。如果数据量上 TB，mysqldump 就太慢了，这时候物理备份更靠谱，比如用 Percona XtraBackup，它直接拷贝数据文件，速度快得多，而且支持增量备份。我的习惯是：10 GB 以下用 mysqldump，10 GB 以上用 XtraBackup，超过 100 GB 老老实实做物理备份加增量。备份完成后一定要做一次校验，比如计算源库和目标库表的行数、checksum，别等迁移完了才发现少了几万条。
数据导出以后，导入新库前的准备工作常被忽略。新库的配置要根据硬件重新调。比如旧库用的是机械硬盘，新库是 SSD，innodbiocapacity 和 innodbflushlogattrx_commit 这些参数就得改。还有字符集，主流是 utf8mb4，旧库可能还是 latin1，导入前先把新库的默认字符集设好，否则中文会直接变成问号。导入时如果数据量很大，别直接 source 那个几十 GB 的 SQL 文件，太慢了。可以用管道：，或者配合 pv 监控进度。更狠一点，用 mydumper / myloader 并行导出导入，能把时间从几小时压缩到几十分钟。我上次帮朋友迁移一个 300 GB 的库，从阿里云迁到腾讯云，用 myloader 开 8 个线程，原本预估要 4 小时，实际 2 小时搞定。
迁移过程中最怕的是业务还在写数据。如果不是全量迁移完就切，而是需要一段“并行期”，就要上主从复制。比如先把旧库的数据全量备份恢复到新库，然后把新库配置为旧库的从库，开始追 binlog。这一步的关键是 binlog 格式和 GTID。建议旧库开启 row 格式的 binlog，并启用 GTID，这样复制更稳定。追日志时可以用 监控延迟秒数。等延迟降到接近 0，就可以准备切换。但要注意，如果旧库写压力特别大，比如每秒几千个事务，从库可能永远追不上。这时需要考虑限流或短暂暂停业务写入。我见过一个案例，某电商平台大促期间做迁移，从库延迟一直卡在几百秒，只能等大促结束再搞。
切换环节是翻车重灾区。很多人习惯直接修改应用配置里的数据库连接地址，然后重启应用。但这样会出现问题：旧库里可能还有未提交的事务，或者连接池里的老连接没断开，应用仍会连到旧库。正确做法是：先确认从库延迟为 0，然后锁定旧库只读（比如 ），再检查新库的 binlog 位置是否对应，确认无误后，修改应用配置并重启，同时把旧库的读请求也切到新库。这里有个小技巧：如果用的是云数据库，很多厂商提供 VIP 地址切换，只需在控制台点一下，后端自动把流量切过去。如果是自建环境，可以考虑用 ProxySQL 这类中间件，通过修改路由规则实现秒级切换，不需要改应用配置。切换完成后不要马上删旧库，保留至少 24 小时，万一出问题还能回滚。
回滚方案是很多人忽略的。数据迁移就像手术，你得准备“救心丸”。万一新库性能不行，或者数据校验发现不一致，需要快速切回去。最简单的办法是：在切换前把旧库的只读状态解除后，保留一段时间。但这样会面临一个问题——切换期间新库写入的数据，旧库没有。所以更稳妥的做法是：在切换前配置双向复制，或者至少让旧库成为新库的从库，这样切回去数据不会丢。不过双向复制配置复杂，容易产生冲突。我的建议更简单：如果数据量不大，切换后 24 小时内发现问题，直接全量从新库导出再导入旧库，然后切回去；如果数据量大，就在切换前做一次最终的全量备份，保留好，回滚时用这个备份覆盖旧库，然后业务切回去。虽然会丢失切换后一段时间的数据，但总比业务全挂强。
数据一致性校验是一道防线。别以为迁移完了就万事大吉，很多时候因为字符集转换、浮点数精度、或者表结构差异，数据会悄悄对不上。推荐使用 pt-table-checksum，它能逐行对比源库和目标库的每张表，生成差异报告。跑一遍后如果有不一致的行，再用 pt-table-sync 修复。但注意，这两个工具在高并发环境下会消耗大量 IO，最好在业务低峰期使用。我的习惯是先校验核心业务表，再校验全库。发现差异后先分析原因，大多数是字符集或时间戳精度问题。比如 MySQL 5.7 之前 datetime 只支持到秒，5.7 之后支持到毫秒，迁移时如果没注意，数据会被截断。还有一个坑是自增主键：如果旧库和新库的自增值不一样，插入新数据时可能碰撞，校验时要格外留意。
说点实在的。数据迁移不是单纯的技术活，更是管理活。你得和业务方确认好停机窗口、回滚策略、应急预案。写一份操作手册，列明每一步怎么操作、遇到报错怎么处理、谁负责执行、谁负责复核，全部写清楚。迁移当天，开个群，拉上 DBA、运维、开发、业务负责人，每一步执行完都在群里报个“完成”。我见过最稳的团队，会在迁移前做三次演练：第一次在测试环境，第二次在预发环境，第三次在正式环境但选在凌晨业务最低谷时。演练中发现的问题全部记录进文档。正式迁移时，每个步骤都严格按照演练时的流程和参数执行，这样翻车概率基本能降到 5% 以下。数据迁移这件事，慢就是快，稳就是赢。
