干这行这么多年，最怕听到的一句话就是：“数据迁一下，很简单，半天搞定。”说这话的人，要么没亲手干过，要么是刚入行的愣头青。MySQL 数据迁移看着像是导表、导数据、改配置的活儿，但真上手了，坑多得能让你怀疑人生。我自己就栽过跟头，印象最深的是帮一个电商客户做迁移，数据库有 200 多张表，最大的那张订单表快 10 亿条记录。他们原本用的是 MySQL 5.7，想搬到新集群的 8.0 版本，理由是性能更好、功能更全。我心想，逻辑备份加物理恢复，再跑个校验，一天之内应该能完事。结果呢？导出的 SQL 文件有 80 多个 G，导入时卡在一个索引重建上，花了整整 14 小时。客户那边业务停了半天，老板电话打爆，我蹲在机房吃泡面，嘴里都是苦味。后来复盘才发现，问题出在字符集不一致——旧库是 latin1，新库默认 utf8mb4，数据里有大量 emoji 表情，直接报错。你以为迁移就是复制粘贴？太天真了。
数据迁移的核心其实不是“搬数据”，而是“搬逻辑”。数据本身只是一堆二进制字节，数据库里却藏着索引、约束、触发器、存储过程、视图这些逻辑结构。你光把表结构和数据导过去，不考虑这些依赖关系，新库就是个空壳子。比如有些表之间有外键关联，迁移顺序错了，数据插不进去；自增主键如果不指定起始值，新库可能会从 1 开始，和旧库的 ID 冲突。更坑的是时间字段的时区问题。旧库是 CST，新库设成了 UTC，导进去的订单时间全乱了，用户查历史记录，发现凌晨下的单变成了下午，直接投诉到 315。我这朋友就吃过这个亏，迁移完还得手动写脚本修正时间，折腾了两天。所以，迁移前的第一步永远是把旧库的逻辑结构摸清楚。用 SHOW CREATE TABLE 把每张表的建表 DDL 导出来，仔细看有没有非默认的字符集、排序规则、分区策略。索引的命名规则也得统一，不然新库里一堆乱七八糟的索引名，后期维护起来想死的心都有。
选工具也是个技术活，不能光图省事。MySQL 自带的 mysqldump 是老牌工具，稳定是稳定，但坑也不少。默认是单线程导数据，几百万条记录还能扛，到了上亿级别，慢得想摔键盘。我有个同事，用 mysqldump 导一张 10 亿条的表，跑了整整三天三夜，中间网络断了，前功尽弃。后来换成 mydumper，多线程导出，速度提升了十倍以上。但这玩意儿也有脾气，如果表里有大字段（BLOB、TEXT），导出时线程分配不好，容易把内存撑爆。还有热迁移工具，像 gh‑ost、pt‑online‑schema‑change，这些是为不停机迁移设计的，但前提是你得懂锁机制。主从复制时，如果旧库是读写分离架构，从库延迟大，迁移进去的数据和主库对不上，业务就裂了。我的最稳妥玩法是：先用 mysqldump 导出结构，手动建好新库的表和索引；再用 mydumper 多线程导数据；最后用 pt‑table‑checksum 做逐行校验。每一步都记录日志，出错时能精准定位到哪条记录。别嫌麻烦，迁移这事儿，慢就是快。
数据量小的时候，怎么折腾都行。但到了 TB 级别，就得拼硬件和网络了。我见过最离谱的迁移方案，是有人直接把旧库的物理文件拷贝到新服务器上，然后启动 MySQL。结果新版本的 InnoDB 引擎不认旧版本的数据文件，直接崩了。物理迁移必须保证版本一致，MySQL 5.7 的数据文件不能直接给 8.0 用，因为文件格式和元数据存储方式都变了。更稳妥的做法是，用 Percona XtraBackup 做物理热备，备份出压缩包，传到新服务器上解压恢复。这方法速度快，但要求两台机器之间的网络带宽够大，至少万兆网卡。否则，几十个 TB 的数据，光传输就得两天。我那次迁一个金融客户的数据库，数据量有 3 TB，网络只有千兆，传了 40 多个小时。中间还断过一次，得重新校验 MD5，心态直接炸了。后来学乖了，传输前先分区压缩，每个区块传完就校验，失败的只重传那一块。
迁移过程中，最怕的就是数据不一致。你以为数据全过去了，结果业务跑起来发现某些字段是空的，或者数字对不上。原因千奇百怪：有的是旧库里有脏数据，比如日期字段存了 “00‑00‑00”，新库的 sqlmode 严格，直接当成空值忽略；有的是浮点数精度问题，旧库用 float，新库用 decimal，导进去四舍五入，账对不上。更隐蔽的是字符集转换时，生僻字被替换成问号。我有个客户，迁移后发现会员昵称全是 “??”，因为旧库是 gbk，新库是 utf8，gbk 里有的字在 utf8 里没有对应编码，直接丢了。这种问题光靠肉眼查根本查不完，必须用自动化工具做逐行比对。开源的 pt‑table‑checksum 能算每张表的校验和，但面对超大表也会慢。我的做法是：先按主键范围分片，每个片独立校验并行跑，再合并结果。这样能控制时间，不至于跑一天还没出结果。
迁移完了，千万别急着把旧库关掉。我亲眼见过有人迁完就删了旧库，结果新库出了 bug，数据全乱了，想回滚根本没有。正确的做法是，让新库和旧库并行跑一段时间，业务流量慢慢切过去。比如第一天切 10% 的请求到新库，观察是否有报错、延迟或数据不一致；没问题后第二天切 30%，第三天切 50%，直到 100% 全部切完。这期间旧库仍需保持读写，万一新库挂了，能秒级切回来。而且并行期间要监控新库的性能指标，如慢查询数量、锁等待时间、缓存命中率。有时候旧库的某个查询只跑 0.1 秒，到了新库因为版本差异或索引没优化好，直接变成 10 秒，业务就卡死。我那次迁一个论坛数据库，并行阶段发现新库的全文索引查询慢得像蜗牛，原来是新版本改了默认的全文解析器，需要重新建索引。如果一股脑全切过去，用户搜索帖子会等半分钟，估计被骂上热搜。
说个玄学问题：迁移完数据后，新库的性能往往比旧库差，至少头一两周是这样。不是因为你操作有问题，而是缓存还没预热。InnoDB 的缓冲池里没有数据，第一次查询任何表都要从磁盘读，慢是正常的。还有一个冷门原因：新库的统计信息不准确，优化器选错了执行计划。比如旧库的某个字段有索引，旧统计信息显示选择性很高，优化器会走索引；新库刚导入数据，统计信息还没更新，优化器可能以为全表扫描更快，结果反而慢了。解决办法就是手动跑一下 ANALYZE TABLE，或者调高统计信息的采样比例。另外，新库的配置文件别照搬旧库。硬件变了，CPU 核心数、内存大小、磁盘类型都不一样，参数得重新调。比如旧库是 HDD，线程池大小设 128；新库是 NVMe SSD，同样设置反而会浪费性能。我一般建议迁移后至少观察两周，期间逐步调整 innodbbufferpoolsize、querycachetype 等参数，找到新硬件下的最优值。
数据迁移说到底是一场没有硝烟的战争。你面对的不是简单的数据搬运，而是一个活生生、有自己脾气的系统。版本差异、字符集陷阱、网络瓶颈、硬件变化，每一个细节都能让你翻车。但反过来想，每次迁移也是一次重生的机会——你可以趁机清理旧库里的垃圾数据，重建索引，优化表结构，甚至重新设计数据模型。我有个客户，迁移前老库里有大量空表和废弃字段，趁这次机会全删了，新库的查询性能提升了 40%。所以，别把迁移当成苦差事，而是一次数据库的深度体检。下次老板再跟你说“数据迁一下，很简单”，你就笑笑，把这篇干货甩给他。该准备脚本的准备脚本，该买泡面的买泡面，因为大概率，你又得熬几个通宵。
