上周帮一个朋友处理数据库迁移的事，他公司业务刚起步，之前图省事把 MySQL 跑在一台老旧的服务器上，现在用户量上来，动不动就卡死。他急得满头包，问我怎么办。我说，搬呗，把数据库迁到新服务器上去。他愣了一下，问那是不是得停业务好几个小时？我说，你那是十年前的做法了。
很多人一听到“数据库迁移”，脑子里蹦出来的就是“停机维护”四个大字，仿佛这是道过不去的坎。其实并非如此。MySQL 从 5.6 开始就支持在线 DDL，到了 5.7 和 8.0，迁移工具更是多得让人眼花缭乱。关键是要先搞清楚自己的情况：数据量大不大、业务能不能接受短暂的只读窗口、网络带宽够不够。弄清这些，才能选对路子。
就拿最常见的 mysqldump 来说吧。这玩意儿最原始，但最稳。你登录到旧服务器，跑一条 mysqldump 命令，把整个库倒成 SQL 文件，然后传到新服务器，再用 mysql 命令导进去。听起来很简单，但坑全在细节。比如默认参数会锁表，业务写操作全卡住。所以要加上 --single-transaction 参数，让 InnoDB 表通过事务实现一致性读，不锁表。但要注意，MyISAM 表仍会被锁，如果库里还有 MyISAM 表，就别指望零停机了。
我那个朋友的数据量大概有 80 GB，mysqldump 导出压缩后也就 20 GB，网络是千兆内网，传文件只要几分钟。但导入时出了岔子——新服务器上 MySQL 的配置没调，innodbbufferpoolsize 仍是默认的 128 MB，导致导入速度慢得像乌龟爬。我让他先改配置文件，把 buffer pool 调到机器内存的 70%，重启 MySQL 后再导，速度直接提升了五六倍。所以说，迁移不只是搬数据，环境配置也得同步跟进。
如果说 mysqldump 是手动挡，那 MySQL 官方出的 MySQL Shell 就是自动挡。它的 “Instance Dump Utility” 能把整个实例或指定库导出成逻辑备份，还支持多线程并行导出导入。对于几百 GB 甚至上 TB 的数据，这个效率比 mysqldump 高出一大截。而且它还能做在线克隆，意思是新服务器可以直接从旧服务器拉数据，过程中旧服务器照样读写。我去年帮一个电商客户迁移，数据量 1.2 TB，使用 MySQL Shell 并行导入，加上千兆网络，实际只花了两个半小时，业务几乎没有感知。
当然，如果业务要求零停机，或者只有几秒钟的窗口，就需要更高级的玩法——主从复制。原理很简单：在新服务器上搭建从库，让它实时同步旧服务器的数据。等两边数据完全一致后，把业务连接切到新服务器，迁移就完成。搭建从库时，记得开启 gtidmode=ON，这样主从切换时不会丢数据，也不容易出乱子。我有个做金融系统的朋友，每次迁移都是这么干的，切换时间控制在 10 秒以内。
不过主从复制有前置条件：旧服务器和新服务器之间的网络必须稳定，延迟要低。如果跨机房甚至跨地域，延迟一高，从库就跟不上主库的写入速度，数据会滞后。此时可以考虑半同步复制，或者使用中间件做读写分离，先把读流量切过去，等数据追上后再切写流量。但说实话，这些方案对运维能力要求不低，小团队还是别轻易尝试。
还有一个容易被忽视的点：字符集和排序规则。很多人迁移后发现中文变成乱码，或者查询结果排序不对，十有八九是字符集没有对齐。MySQL 8.0 默认字符集是 utf8mb4，但很多老库仍是 latin1 或 utf8mb3。迁移前一定要检查旧库的字符集设置，然后在导出时指定 --default-character-set=utf8mb4，导入前新库也要建好对应的字符集。别嫌麻烦，这一步省了，后面能省一堆排查时间。
多说一句：迁移完一定要做验证。不是看几条数据就完事，要跑一遍业务的核心流程，比如用户注册、下单、支付这些关键操作。我见过最离谱的案例，有人迁移后发现所有存储过程都丢了，因为导出时忘了加 --routines 参数。还有一次，迁移后自增主键的起始值变了，导致业务插入数据时报主键冲突。这些细节只有在真实场景下才能暴露出来。
所以回到开头的问题：数据库迁移到底难不难？说难也难，说简单也简单。工具和方法都在，只要能根据实际情况选对方案，并把每一步细节踩实。别一上来就想搞花活，先在小库练手，把流程跑通，再上生产环境。毕竟数据这东西，丢了就是真丢了，谁赔得起？
