这事儿我干过太多回了，每次换服务器，最头疼的就是那堆数据库。说实话，MySQL迁移看着简单，实际操作起来坑不少。今天就跟大家聊聊我从旧服务器搬到新服务器的那些门道。
先说最常见的方案：mysqldump。这玩意儿就像给数据库拍个快照，把数据和结构都导成SQL文件。我一般这么用：先在旧服务器上执行，然后把文件传到新服务器，再跑。但这里有个细节：如果数据库特别大，比如几十个G，直接导出可能会把服务器搞死。我建议加上参数，这样导出时不会锁定表，对线上业务影响小。另外，别忘了和，很多人丢过存储过程和触发器的坑。
接着说物理迁移，更适合大库。直接复制数据文件，比如InnoDB的.ibd文件。步骤是：先停掉旧服务器的MySQL服务，把整个数据目录打包，传到新服务器，然后配置好相同的路径和权限。这招快，但有个致命问题：版本必须一致或兼容。我吃过亏，5.7的数据文件直接丢到8.0上，结果启动报错。所以迁移前一定检查版本号：。如果版本差太多，还是老老实实用逻辑备份吧。另外，复制时注意文件权限，MySQL用户要能读写，否则启动不了。
还有一种骚操作：主从复制。适合需要零停机迁移的场景。先在旧服务器上开启binlog，配置一个主库，然后在新服务器上搭从库，等数据同步完成后，切换应用指向新库。这需要点技术底子，但效果确实好。我干过最狠的一次，直接把一个100G的库在半小时内切完，用户完全没感觉。关键点：主库的server-id必须唯一，binlog格式建议用ROW，避免数据不一致。还有，复制用户权限要给对，，别漏了。
数据一致性是迁移的灵魂。不管用哪种方法，迁移后都要验证。我习惯写个脚本，对比新旧库的行数、checksum或者关键字段的摘要。比如跑几个大表，或者用全表校验。千万别只跑一次就信了，最好业务低峰期再跑一遍。另外，别忘了检查外键和索引，有时候导出导入后，索引顺序会变，影响查询性能。我见过最坑的：迁移后一个查询从0.1秒变成10秒，就是因为索引丢失了。
网络传输也是个坑。如果新旧服务器不在同一机房，甚至跨地域，带宽和延迟就是大问题。我建议用压缩传输：，管道直连，省去中间文件。但要注意，网络不稳定时容易断，最好加个命令监控进度。还有，如果数据量超过10G，我推荐用，它支持并行导出，能快不少。
权限和配置千万别忘。旧服务器上可能有自定义的MySQL用户、密码、权限，导出时用确保包含表。新服务器上还要检查配置，比如字符集、时区、最大连接数。我见过一个案例：迁移后中文变成乱码，就是因为旧库是utf8mb4，新库默认是latin1。所以迁移前，先在新库上，对不上就改配置。还有，如果用了视图或者存储过程，记得检查定义者（definer）是否存在，否则会报错。
留条后路。迁移不是一次性的游戏，我每次都会保留旧服务器至少一周，万一新库出问题，能快速回退。另外，迁移后别急着删旧数据，先在新库上跑几天业务，观察慢查询日志和错误日志。我有个习惯：迁移完成后，用分析一下新旧库的查询模式，看有没有异常。还有，如果迁移过程中遇到报错，比如，别慌，查日志：，大多数问题都能找到答案。
说到底，MySQL迁移这事儿，技术不难，难在细心。把每一步都想清楚，留好回滚方案，比啥都强。下次你换服务器时，别光盯着命令，多想想数据一致性、网络、权限这些细节，准没错。要是实在拿不准，先在测试环境演练两遍，比出问题再救火省心多了。
