把 MySQL 数据库从一台老旧的服务器搬到更强大的机器上，听起来像是一次简单的复制粘贴，却藏着不少坑。本文不说那些官方文档里出现的术语堆砌，而是把真实的迁移过程拆解成几步，让你能一步步跟着操作，避免在搬家路上翻车。
迁移前的准备工作往往决定成败。备份全库或全库的二进制日志是必须的，这样出现问题可以迅速回滚。检查源库和目标库的 MySQL 版本是否匹配，最好保持一致，避免出现兼容性报错。还要确认网络连通性和权限，给迁移用户授予足够的读写权限，别在关键时刻卡住。
正式搬家前，需要把数据库停掉写入，或者使用主从复制把实时变更同步过去。如果是停写，可以执行 FLUSH TABLES WITH READ LOCK，随后导出数据，释放锁。若采用复制，则先搭建好从库，让它追赶上主库的最新位点，等确认无误后再切换。
数据迁移本身有两种方式：逻辑导出（mysqldump）和物理文件拷贝。逻辑方式适合小库或结构简单的情况，但会慢一点；物理方式直接把 ibdata、myibd 等文件拷贝过去，速度快但要匹配相同的文件系统和配置。这里推荐物理拷贝，只要把数据目录复制到新机器的 my.cnf 里对应的目录即可。
把数据搬到新机器后，别急着启动。先检查 my.cnf 是否把数据目录、端口、字符集等关键参数配好，然后启动 MySQL，观察日志有没有报错。启动成功后，用客户端连接测试一下，确认能读取到完整的表和数据，别让错误信息藏在日志里不敢看。
迁移后最麻烦的事是数据完整性检查。可以用 CHECKSUM TABLE 或 pt-table-checksum 对比源库和目标库的校验和，确保每个表的数据一致。随后调优新库的配置参数，比如 innodbbufferpoolsize、maxconnections 等，让它在新环境下发挥最大性能。别忘了重新生成统
计信息，因为统计信息在迁移后可能过期，影响查询执行计划。建议在目标库上运行 为所有表更新统计信息，再配合 检查关键查询的索引使用情况。如果发现某些表的索引选择性变差，可以重新评估索引策略，删除冗余索引或补充联合索引。这一步虽小，却能避免大量线上慢查询的尴尬。
迁移后的应用层测试同样不可忽视。建议搭建一个临时域名或测试环境，让开发团队模拟线上流量跑一遍核心业务逻辑，观察接口响应时间和数据库连接池是否正常。比如我曾经遇到过迁移后某个业务表的主键自增值被重置，导致插入报主键冲突，就是因为数据导出时没带自增偏移量。这类问题在压力测试阶段暴露，总比上线后报警强。
如果业务允许灰度切换，最好分批次把读流量和写流量逐步导向新库。先切 10% 的读请求，观察新库的 CPU 负载和慢查询日志，确认稳定后再切更多。写流量迁移更要谨慎，可以通过双写方案先同时写入新旧两库，对比一段时间的数据差异，等无异常后再关停旧库写入。这期间需要做好回滚预案，一旦新库出现性能瓶颈或数据不一致，能迅速切回旧库。
最后别忘了清理旧库资源和更新监控告警。旧库如果不再使用，要及时回收磁盘空间和 IP 资源，避免后续运维混淆。新库的监控指标需要重新配置，重点监控连接数、查询延迟、磁盘 IO 和复制延迟（如有从库）。同时更新 DBA 手边的运维文档和拓扑图，把这次迁移的细节、变更时间点、注意事项都记下来。数据库迁移不只是搬数据，更是对团队流程和应急能力的检验，每一次成功迁移，都应该沉淀为下次更从容的经验。
