上周三晚上十一点，我盯着屏幕上的迁移进度条，手心全是汗。那是一个承载了三年订单数据的核心表，2.1亿行，将近80GB。旁边坐着的DBA老张叼着烟，烟灰落了一键盘也没顾上擦——他在等一个结果：表结构切换那三秒钟，会不会有新的写入进来。
进度条走完，业务侧零报错，老张把烟掐了，说了句“成了”。那一刻我突然意识到，MySQL表迁移这事儿，真正难的从来不是数据怎么拷过去，而是怎么让业务在切换瞬间感觉不到疼。今天就把我们踩过的坑、趟出来的路，拆成五个关键步骤，说点实在的。
第一步，先把“基线数据”和“增量数据”的边界划清楚。很多人一上来就mysqldump全量导出，然后导入，完事。但你要知道，在导出到导入这段时间里，线上还在不停写入，你导出的那个快照早就过时了。我们当时的做法是：先用或者拉一个一致性快照，记录下binlog的position。这个position就是你增量的起点。别小看这一步，它决定了你后面所有增量同步能不能对得上。
第二步，增量同步必须用工具，别手写脚本。我们最初试过自己写Python脚本去轮询binlog，结果遇到DDL就崩，遇到大事务就延迟，实在扛不住换成了或者。这两个工具能把binlog解析成JSON格式的增量事件，实时推送到新表所在的实例。这里有个坑：老表和新表的字段顺序、类型定义必须完全一致，哪怕是和这种显示宽度差异，都可能让canal解析报错。我们当时就栽在和上，数据对账差了0.01，排查了整整一个下午。
第三步，对账是迁移的命门，别省。增量同步跑起来之后，你得知道同步得对不对。最笨也最有效的办法是：拿老表的和跟新表比对。但2亿行的表，全表count一次要跑十几分钟，业务高峰期根本不敢跑。我们的做法是分段对账，比如按主键ID范围切成100个区间，每个区间单独比对行数和校验和，并行跑，五分钟搞定。还要注意，如果老表有频繁的update操作，对账期间数据一直在变，那你得先暂停写入或者接受“对账那个瞬间的最终一致性”。
第四步，切换那一瞬间，要有个“闸门”。这可能是整个迁移里最刺激的环节。我们的方案是：在业务代码里加一个开关，比如配置中心里的一个布尔值。切换前先把这个开关置为“只读”，意思是业务只能查不能写。等存量增量追平，再把开关切到“新表写入”。听起来简单，但有个细节——老表上可能有长事务或者慢查询，你得先杀掉这些会话，否则它们持有的锁会让你的切换卡死。我们当时有个统计查询跑了40分钟没结束，差点把切换窗口堵死。后来学乖了，切换前先查，把超过30秒的查询全部kill掉。
第五步，切换后的观察期，别急着删老表。我们定了个规矩：新表上线跑满72小时，期间每天跑两次对账，同时监控主从延迟、慢查询、锁等待。如果一切正常，才把老表改成归档表，再等30天确认没问题才物理删除。这期间有个小技巧——把老表重命名为，新表叫，这样万一出问题，改个名字就能回滚。别嫌麻烦，我们隔壁团队就是切换后没留后路，第二天发现有个报表SQL用了，新表索引名对不上，直接线上故障。
说实话，做了这么多年数据库迁移，我最大的感受是：工具和命令都是公开的，网上教程一抓一大把，但真正拉开差距的是对细节的把控。比如binlog的格式和格式，解析结果完全不一样；比如新表的自增主键偏移量没设好，插入数据时可能撞上老表的自增ID；比如字符集不一致导致的乱码，这种问题在数据量小的时候根本暴露不出来，一上生产就炸。
还有一点容易被忽略——迁移期间的监控。我们当时在Prometheus里专门配了一张dashboard，实时展示老表和新表的写入速率差、binlog消费延迟、对账失败条数。一旦发现增量同步的延迟超过5秒，立刻报警。别等到切换前才去检查，那时候发现延迟已经来不及追了。我记得有一次因为网络抖动，canal的消费延迟飙到了三分钟，幸好监控提前发现，我们调整了消费端的并发线程数，才在切换窗口前追平。
说回开头那晚。老张后来告诉我，他其实心里也没底，但流程走到那一步，每一步都验证过了，剩下的就是等待。数据无损切换，从来不是靠某一招鲜，而是靠这五步环环相扣：划清基线、增量同步、分段对账、切换闸门、观察留后路。每一步都有坑，但每一步也都有对应的解法。你只要把每一步都走扎实，MySQL表迁移这事儿，其实没那么玄乎。
下次你遇到类似的需求，不妨把这五步打印出来贴在工位上。等什么时候你能在切换窗口前五分钟，还有心情跟同事开个玩笑，那说明你真正掌握了这套打法。
