干这行的人，迟早都会碰上数据库迁移这档子事。甭管你是从云上迁到云下，还是从一台破旧服务器搬到新机器，Linux环境下的MySQL迁移，就像搬家一样，看着简单，实则处处是坑。今天这篇，咱们就好好掰扯掰扯这其中的门道，把那些血泪教训揉碎了讲给你听。
很多人一上来就想着用mysqldump，这没错，但得看你数据量有多大。如果你那库只有几百兆，导出再导入，几分钟完事，那确实轻松愉快。可一旦数据量上了几十个G，甚至上百G，mysqldump就成了龟速，而且中途一个网络抖动或者磁盘满了，前功尽弃，那滋味，比吃了苍蝇还难受。我见过不少新手，拿着一个5G的库用mysqldump导，结果导了俩小时没完，卡死在某个大表的索引重建上，气得直拍桌子。所以，动手之前，先掂量掂量自己手里这坨数据到底有多大，这决定了你该走哪条路。
要是数据量真的大，咱们就得换思路了。物理迁移，直接拷贝数据文件，反而是最实在的。具体操作其实不复杂：先停掉MySQL服务，确保数据文件是干净一致的，然后把整个datadir目录打包压缩，传到新机器上解压，再稍微调整一下权限和配置文件，起服务就完事了。这方法速度快得惊人，尤其适合那种大库。但前提是，新旧机器的MySQL版本最好保持一致，至少大版本要一致，不然很可能因为文件格式不兼容，起来之后一堆报错，那场面可就更热闹了。另外，千万别忘了，拷贝之前一定要先停服务，你要是热着拷贝，那数据文件处于写状态，拷过去就是个残缺品，查数据对不上账，哭都来不及。
聊完了数据怎么搬，接下来得说说配置这茬。新机器上的配置文件，可不能直接照抄老机器的。硬件配置不一样，内存大小不一样，磁盘类型也不一样，这些参数都得跟着变。比如innodbbufferpool_size，老机器内存32G，你设了20G，新机器要是只有16G内存，你还设20G，那MySQL一启动就崩，或者疯狂使用交换分区，性能比乌龟还慢。还有那些日志文件大小、连接数上限，都得根据新机器的实际情况重新评估。很多人图省事，直接打包整个配置文件，结果新机器跑起来各种问题，排查半天，发现是配置不匹配，这种低级错误，真不该犯。
迁移过程中，最容易忽视的其实是权限和账号。MySQL的用户权限是存在系统表里的，如果你只迁移了业务库的数据，而忘了把mysql库里的用户表也搞定，那新机器上所有的应用都会连不上数据库。最稳妥的做法是，在旧机器上用mysqldump把mysql库单独导出来，或者用工具生成所有用户的授权语句，然后到新机器上重新执行一遍。千万别嫌麻烦，这步要是漏了，到时候一堆程序报连接错误，你挨个排查，那才叫欲哭无泪。我甚至遇到过，有人迁移完了，发现root密码都变了，自己都登不进去，那就更尴尬了。
还有个大坑，就是字符集和排序规则。老库可能用latin1，新库你初始化的时候用了utf8mb4，数据导进去，中文全变成问号，或者排序错乱。这种问题隐蔽性极强，不仔细查根本发现不了。所以迁移之前，一定要检查所有表的字符集，最好统一转成utf8mb4，免得以后开发新功能时，数据乱成一锅粥。另外，存储过程、函数、触发器这些，也得单独导出来，别以为数据表过去了就万事大吉，这些逻辑对象丢了，业务跑起来会各种报错，到时候再回头补，那工作量可就不小了。
迁移完事儿，数据也导进去了，服务也起来了，是不是就完了？还早呢。必须做一次全量的数据校验，比如对比一下表行数，抽查几个关键字段的数据，看看有没有对不上号的地方。这一步绝对不能省，你想想，数据迁移过程中，万一有个网络闪断，或者磁盘写入出错，数据就可能悄悄丢了。你不校验，等业务跑起来发现数据对不上，那时候再回溯，成本就高了去了。顺便，把慢查询日志打开，观察几天，看看新机器上有没有性能瓶颈，毕竟硬件变了，SQL执行计划也可能跟着变。
说一句，数据库迁移这事儿，永远没有“绝对稳妥”的方案。哪怕是同版本、同配置的机器，也可能因为环境差异出幺蛾子。所以，迁移前一定要做好备份，最好是全量备份加binlog日志都留一份，万一新机器上出了不可逆的问题，咱们还能退回老机器继续跑，不至于业务停摆。备份这东西，平时觉得占地方，关键时刻能救命，这话一点不虚。
Linux下MySQL数据库迁移，说白了就是细心加耐心，把每一步都走到位，把每一个细节都检查到。别迷信什么一键迁移工具，那些玩意儿在复杂场景下往往不靠谱。踏踏实实按照流程来，多测几遍，多验证几次，你的数据才能安安稳稳地搬进新家。说到底，数据库这东西，稳字当头，慢一点没关系，出事儿才是真麻烦。
