上周一个朋友半夜给我打电话，说公司用了三年的 MySQL 数据库要迁移到新服务器，数据量有 200 多 GB，问我怎么搞最稳妥。我问他有没有做过测试，他说直接在生产环境试试。我当时就惊了，这兄弟胆子真大。数据库迁移说白了就是把一堆数据从一个地方搬到另一个地方，看着简单，但踩过的坑能写满好几页。今天就跟大家聊聊我这些年积累的实战经验，从最简单的工具到复杂的增量同步，把每个方法背后的坑都掰扯清楚。
先说最基础的 mysqldump，这个工具几乎每个搞 MySQL 的人都用过。它的原理特别直白：把整个数据库的结构和数据导出成 SQL 文件，然后在目标服务器上跑一遍。200 多 GB 的数据用这种方式，导出时间至少半小时，导入时间更夸张，可能得两三个小时。而且有个大坑：mysqldump 默认是单线程，你服务器 CPU 再强也白搭，它只用一个核心。我见过有人用 参数来保证一致性，但忘了加 ，结果大表直接撑爆内存。还有个更隐蔽的问题：mysqldump 导出的 SQL 文件如果包含存储过程、触发器和事件，默认可能不会包含，需要手动加上 和 。所以用这个工具前，最好先在小库测试一下，看看有没有遗漏的对象。
如果你的数据量超过 100 GB，或者业务对停机时间有严格要求，那就得上物理拷贝这招了。思路很简单：直接把 MySQL 的数据目录整个复制过去。但这里有个关键前提：源库和目标库的版本必须一致，至少大版本要相同，比如 5.7→5.7、8.0→8.0。跨版本拷贝大概率会出问题。具体操作时，先在源库执行 把表锁住，然后拷贝 、、 等文件。拷贝完别忘了 。还有一个细节很多人会忽略：MySQL 的配置文件里有路径设置，如 、，这些目录在目标服务器上必须存在，否则 MySQL 启动会报错 “Can't find file”。我见过最惨的案例：有人把文件拷过去后忘了检查路径，结果服务启动报错，折腾了两小时才发现是路径问题。
如果业务不能接受任何停机，那就要上主从复制了。这个方案的核心思路是：先搭建主从关系，让新服务器从旧服务器同步数据，等两边数据完全一致后，再平滑切流。具体步骤分三步：第一步，在源库上开启 binlog，设置 ，创建复制账号并授予 权限。第二步，在目标库上执行 ，指定源库的 IP、端口、binlog 文件名和偏移量。第三步，启动 ，观察 参数，当它变成 0 时，说明两边数据一致。但有个坑：如果表没有主键或唯一索引，且 binlog 格式是 ROW 模式，复制会非常慢，因为 MySQL 需要全表扫描才能找到要更新的行。我见过一个表 500 万行、没有主键，复制延迟从几秒飙到几小时。所以做复制前，先检查表结构，必要时补上主键。
还有一种更复杂的情况：跨版本迁移，比如从 MySQL 5.7 迁到 8.0，或从 Percona Server 迁到 MariaDB。这时 mysqldump 和物理拷贝都不太靠谱，需要逻辑备份并手工调整。我一般先用 mysqldump 导出结构和数据，然后在目标库上导入。但 8.0 与 5.7 有不少差异，例如 8.0 默认字符集是 ，而 5.7 常用 ，导入时如果字段包含特殊字符就可能报错。还有 8.0 废弃了 函数，存储过程里用了会直接报错。更麻烦的是，8.0 的 data dictionary 改成了 InnoDB 存储，之前直接查询 表的方式已经失效。跨版本迁移前，一定要在测试环境完整跑一遍导入流程，把所有报错记录下来，逐一处理。我上次迁一个项目，光处理兼容性问题就花了三天，但比起生产环境出问题，这点时间值得。
除了工具选择，还得考虑数据一致性验证。很多人迁移完就以为完事了，结果业务跑起来发现数据不对。我的习惯是：迁移完成后，在源库和目标库各跑一次 checksum。MySQL 有 语句，可以对整张表计算校验和，但它会锁表，生产环境要慎用。替代方案是写脚本，逐表统计行数，再随机抽几条记录比对字段值。还有一种更实用的方法：在业务低峰期，对比源库和目标库的 binlog 位点，如果一致，说明数据已经完全同步。别忘了检查视图、存储过程和函数，这些对象在迁移过程中最容易出问题。我见过有人迁移完后视图查不到，原因是引用的表名大小写变了。
说个很少有人提的细节：网络带宽。200 多 GB 的数据，如果服务器在同一个机房，千兆网络下大概半小时能传完。但如果目标库在另一个城市，甚至跨云服务商，传输时间可能翻好几倍。我遇到过最夸张的情况：两个机房之间只有 10 M 的专线，传 200 GB 数据理论上需要 46 小时，实际因为网络抖动，花了整整三天。所以迁移前一定要先测网速，用 iperf 或者 scp 传个大文件试试实际带宽。如果带宽不够，可以考虑压缩传输，例如用 配合管道，把 mysqldump 的输出直接压缩后传过去。还有个“骚操作”：先把数据拷贝到硬盘上，再快递寄过去。我有个朋友就这么干过，从上海寄到北京，顺丰次日达，比网络传输快了不少。
写到这里，我想起刚入行时犯的一个低级错误：迁移前忘了检查目标服务器的磁盘空间。那会儿我导出一个 20 GB 的 SQL 文件，结果导入到一半报错 “Disk full”，才发现目标服务器只有 15 GB 可用空间。后来我养成了一个习惯：迁移前先跑 ，确认目标服务器的磁盘空间至少是源库数据的两倍。因为 mysqldump 导出的文件是文本格式，虽然比实际数据库占用的空间小，但导入时 MySQL 需要创建临时表、排序文件，空间占用可能翻倍。如果空间不够，采用物理拷贝的方式可能更省空间。数据库迁移就像搬家，提前规划比动手操作重要得多。每个环节都有坑，只要把每个步骤都验证一遍，踩过的坑就会变成经验。下次再有人问我怎么迁移数据库，我会先问他：你准备好花多少时间做测试了？
