聊到 MySQL 数据库迁移，很多人第一反应就是“导出 SQL 文件，再导入新库”。这种做法在数据量小、结构简单的场景确实够用，但碰到几十 GB 甚至 TB 级的数据，或者业务不能停的情况，这种“土办法”就会让人崩溃。我见过太多人在迁移时翻车，要么数据丢失，要么业务中断半天，被老板骂到怀疑人生。其实数据库迁移本质上是数据、结构、权限、配置的完整搬迁，而不仅仅是“导出导入”四个字。想把它做好，得先弄清楚场景：是从旧服务器迁到新服务器？还是从 MySQL 5.7 升级到 8.0？是单库迁移还是全实例迁移？不同场景对应的工具和策略完全不同。
先说说最常见的“同版本全量迁移”。如果你只是换一台性能更好的机器，数据量在 10 GB 以内，业务可以停机 1‑2 小时，mysqldump 完全够用。但很多人使用 mysqldump 时踩过一个坑：默认导出会锁表，导致业务写入阻塞。正确做法是加上 参数，对 InnoDB 表做一致性快照，这样导出过程中其他会话还能正常读写。另外，导出时别忘了加上 和 ，否则存储过程和触发器会丢失。导入时更要注意字符集问题，很多人导出的 SQL 文件是 utf8mb4，但目标库默认字符集是 latin1，导入后中文全变乱码。所以导入前最好检查目标库的 和 ，确保和源库一致。如果数据量超过 10 GB，mysqldump 的导入速度会慢得让人抓狂，因为它是逐条执行 SQL 语句的。
这时候就该上物理备份工具了，比如 Percona XtraBackup。它的原理是直接拷贝数据库的物理文件，不经过 SQL 解析层，速度比逻辑备份快 10 倍以上。我有个朋友迁移一个 300 GB 的库，用 mysqldump 导了 8 小时还没完，换成 XtraBackup 后，全量备份加恢复只用了 40 分钟。使用 XtraBackup 时要注意两点：第一，备份前要确保源库的 redo log 和 binlog 配置正确，否则可能备份失败；第二，恢复时目标机器的操作系统和 MySQL 版本必须和源库一致，否则文件格式不兼容。物理备份虽然快，但灵活性差，不能像 SQL 文件那样只恢复某个表或某条记录。因此建议物理备份用于全实例迁移，逻辑备份用于小规模或选择性迁移。
如果业务不能停，那就得考虑增量迁移和在线迁移。MySQL 自带的复制功能是个好选择：先在旧库上开启 binlog，然后在新库上建立主从复制关系，这样旧库的数据会实时同步到新库。等数据追平后，把应用切换到新库，再切断复制即可。这个方案听起来简单，但实操中坑不少。比如 binlog 格式必须使用 ROW 模式，否则某些操作在主库上执行后，从库可能无法正确解析。还有，如果旧库已经运行很久，直接配置复制时，需要先手动做一次全量备份，再基于该备份搭建从库，否则起始点对不上。复制过程中如果网络抖动，可能导致延迟飙升，这时要监控 指标，超过 10 秒就需要优化网络或增加带宽。
更棘手的场景是跨版本迁移，比如从 MySQL 5.6 迁移到 8.0。这时直接复制行不通，因为不同版本的 binlog 格式有差异。我的建议是分两步走：先用 mysqldump 或 XtraBackup 做全量备份，然后在目标库上导入。但导入前必须检查源库的 SQLMODE，因为 MySQL 8.0 默认启用了严格模式，而 5.6 可能允许一些不规范写法，例如向 NOT NULL 字段插入空字符串。我见过有人迁移后，原本能正常运行的插入语句全部报错，排查了两天才发现是 SQLMODE 的问题。所以迁移前一定要在测试环境跑一遍所有业务 SQL，看看有没有兼容性问题。另外，MySQL 8.0 废弃了 函数和 插件，如果应用里用了这些特性，需要提前改为 。
数据校验是迁移中最容易被忽视的环节。很多人以为数据导过去就完事了，结果上线后才发现某些表的数据不一致。我推荐使用 来校验源库和目标库的数据一致性，它会逐表计算 checksum 并对比。如果发现不一致，再用 修复。不过这两个工具会对性能产生影响，建议在业务低峰期运行。还有一个更简单的办法：在迁移前后分别执行 对比记录数，虽然不能保证每行数据都相同，但至少能发现明显缺失。对关键业务表，建议做随机抽样校验——随机抽取 1000 条记录，对比字段值是否完全一致。
迁移完成后，千万别急着切流量。先在新库上跑一遍应用的回归测试，尤其是涉及写入和事务的操作。我有过一次惨痛教训：迁移后忘了重建用户和权限，导致所有应用连接都报 “Access denied”。MySQL 的用户信息保存在 表里，使用 mysqldump 导出时需要加上 参数，这样导入后会自动刷新权限表。另外，如果目标库的硬件配置不同，比如从机械盘换成 SSD，或者 CPU 核心数变了，建议重新调整 、 等参数。默认配置通常针对通用场景，但你的业务可能有写多读少或读多写少的特性，参数调优能让性能提升 30% 以上。
说一个很多人忽略的点：迁移方案一定要有回滚计划。我见过有人迁移到一半网络断了，全量备份还没传完，但旧库已经被锁，业务直接瘫痪。所以迁移前要确保旧库的数据和配置都完好无损，最好手动做一次全量备份并存放在安全位置。如果迁移过程中出现不可逆的错误，比如新库数据损坏，需要能够快速回退到旧库。建议在正式迁移前演练一次，尤其是大库迁移，模拟真实环境跑一遍流程，记录每一步的耗时和潜在问题。这样正式迁移时，你心里有数，也能快速定位异常。记住，数据库迁移不是单纯的技术活，而是项目管理活，考虑得越周全，出错的概率就越低。
