数据库迁移这事儿，听着挺吓人，但说白了就是搬家。你从老房子搬到新房子，东西得一件件打包、运输、再拆开摆放，区别只在于搬的是数据。我见过太多人一上来就慌，生怕数据丢一根毛，结果手忙脚乱搞出事故。其实只要把步骤拆开、每一步都想清楚，这事儿没那么玄乎。
第一步是搞清楚手里有什么、要搬去哪里。比如源库是 MySQL 5.6 还是 8.0，目标库是阿里云 RDS 还是自建的 Ubuntu 服务器，甚至是从老机器迁到新机器。不同版本之间，存储引擎、字符集、SQL 语法都有坑。我有个朋友从 5.6 直接迁到 8.0，结果因为默认字符集从 utf8 变成了 utf8mb4，索引长度限制变了，建表语句直接报错。你得先看官方文档，或者至少跑个 把配置摸清楚。这一步花不了半小时，却能省下后面三天的时间。
接下来是备份。别信什么“我数据量小，直接导就行”，那是没吃过亏。哪怕只有几万条记录，也得先做个全量备份。MySQL 自带的 够用，但要注意参数。比如 能保证 InnoDB 表的一致性，不加这个导出时别人刚好在写数据，导出的结果可能前后不对。 和 也要带上，除非你确定新库不需要存储过程和触发器。我习惯跑完备份先检查文件大小，再随便抽几条记录比对，确认没有少漏。这一步是保险，不是形式。
然后才是正式导出。如果数据量大，比如几十 GB， 就有点慢。这时候可以试试 把表导出成 CSV，或者用 这种并行工具，速度能快好几倍。 的好处是能按表拆分文件，导入时也能用 并行恢复。但并行工具对服务器负载有要求，生产环境最好在低峰期操作。导出时还要留意字符集，必须加上 ，否则中文字符到新库可能变成问号。导出的 SQL 文件或 CSV 文件记得压缩一下，能省一半空间。
到了目标库，准备工作不能省。先建好数据库和用户，权限要到位，例如 。然后检查目标库的配置，像 要设大点，默认 4 M，导入大文件时会直接撑爆。我之前导入一个 1 G 的 SQL 文件，忘了改这个参数，MySQL 直接断开连接，查了半天才找到原因。还有 ，如果目标库内存够，设成 70% 左右，能加快写入速度。这些细节看似琐碎，却是卡点所在。
导入这一步，最怕中断。用 直接导入，如果文件大，最好用 让它在后台跑，或者开个 会话。导入过程中，打开另一个终端执行 ，看看进度是否正常。要是报错，比如表已存在或外键冲突，得停下来排查。我习惯在导入前先执行 和 ，关闭约束检查，速度能快不少。导入完别忘了重新开启，否则数据完整性就没有保障。若数据量特别大，可以分批导入，按表或按行数拆开，中间歇一下，避免把服务器搞死。
迁移完不是终点，验证才是关键。先跑 对比源库和目标库每个表的行数，行数不对就得找原因。再随机抽几条记录，检查字段值是否一致，尤其是时间戳、浮点数这类容易出现偏差的类型。如果有业务逻辑，比如用户注册数、订单总金额，最好跑个聚合查询对比。我有个项目，迁移后行数都对，但某表的 没同步，新插入数据直接主键冲突，查了半小时才在 里发现。所以验证不能只靠数量，还要看元数据。
最后一步是切换和清理。确认数据没问题后，停掉业务，或者至少切换只读模式，再把增量数据同步过去。如果使用主从复制，就更简单，但要确保延迟已经追上。业务切到新库后，老库别急着删，至少保留一周，万一新库有问题还能回滚。我见过有人迁移完当天就把老库格式化，结果新库第二天挂了，哭都来不及。数据无价，谨慎点没毛病。整个过程下来，你会发现，数据库迁移不是单纯的技术活，而是流程活——每一步按规矩来，自然就稳了。
