那天凌晨三点，我盯着屏幕上的迁移进度条，心跳和服务器风扇的转速一样快。这不是我第一次做数据库迁移，但每次都是新的折磨。你得把几十 TB 的数据从旧机器搬到新机器，中间不能丢一条记录，不能多一秒宕机。客户那边等着天亮上线，领导在群里催进度，运维兄弟盯着监控屏。这种时候，你会发现，数据库迁移根本不是单纯的技术活，而是一场心理战。
迁移前的几天，我翻来覆去睡不着。不是单纯的焦虑，而是心里没底。旧数据库已经跑了三年，里面存着上亿条订单记录，还有用户积分、交易日志、商品详情。这些数据就像一群不听话的孩子，你根本不知道哪个角落里藏着坏数据。最怕的是迁移到一半，突然发现某个表结构不一致，或者字段类型对不上。我的一个同事因为没提前检查字段长度，迁移后用户手机号全被截断，修复花了整整一周。所以我现在养成了一个习惯——迁移前先做全量数据校验，把表结构、索引、分区、存储过程一个个对着看，连默认值都不放过。
真正动手迁移的那天，我选了凌晨两点。这个时间段用户访问最少，但也不是万无一失。我们采用主从同步加增量迁移的方案，先搭好从库，等数据同步差不多后再把主库切过去。听起来简单，但每个环节都有坑。比如同步延迟，主库写入太快时，从库跟不上，哪怕差个几秒都可能导致数据不一致。那次我碰到从库同步卡住，查了半天才发现是某个大事务锁住了表。于是赶紧手动杀掉事务，重新开始同步，冷汗直冒。这时候才真正体会到监控报警的重要性，延迟超过 10 秒就必须响警报。
数据迁移中最怕的不是技术问题，而是人的问题。有一次我们迁移电商数据库，开发那边临时改了表结构，却没有通知运维，结果迁移脚本跑着跑着就报错，字段对不上。运维兄弟急得直骂娘，开发那边还在睡觉。我们只能暂停迁移、回滚数据，等第二天开会吵了一架才解决。从那以后，我定了个规矩：迁移前 24 小时，所有变更必须冻结，谁改谁负责。这个规矩救了我好几次命，每次有人想赶着上线改东西，我就用它来回绝。
迁移过程中，最考验人的是耐心。数据量大的时候，迁移可能要跑十几个小时。你不能走，不能睡，只能盯着屏幕看日志。中间出错，要立刻判断是重试还是回滚。重试可能浪费时间，回滚可能前功尽弃。我记得有次迁移到 80% 时，突然报了磁盘空间不足的错误。原来新服务器的磁盘分区没配好，数据写不进去，只好暂停迁移、紧急扩容，再重新开始。那晚我喝了五杯咖啡，眼睛都快瞎了。后来我学乖了，迁移前先做两次演练，把各种可能的问题都跑一遍，连磁盘空间、网络带宽、CPU 负载这些细节都不放过。
迁移完不是结束，而是另一个开始。你必须做数据校验，确保两边数据一模一样。我们采用逐条对比加抽样检查的方法，先拿关键字段做 MD5 校验，再随机抽几千条数据手动核对。有时候数字对得上，但业务逻辑不对。比如订单状态，旧库里是数字 0、1、2，新库改成了字符串 pending、paid、shipped，如果转换脚本写错，整个业务就会乱套。我的一个朋友就吃过这个亏，迁移后用户查不到订单，因为状态字段没映射正确，系统误以为所有订单都是无效的，花了三天才修复，客户投诉电话打爆了。
迁移后的性能调优往往被很多人忽略。数据搬过去了，但查询效率可能还不如旧库。旧库的索引、缓存、统计信息都已经调优，新库是干净的，需要重新跑一遍分析。我每次迁移完，都要花几天时间调优，包括重建索引、更新统计信息、调整缓存大小、优化查询计划。有时还要配合业务方改代码，把一些复杂的关联查询改成缓存查询，或者加个中间层。这个过程特别磨人，因为业务方总觉得迁移完就能直接使用，但技术上的坑只能慢慢填。
说到底，数据库迁移不只是搬数据，更是和时间赛跑。你必须在业务不中断、数据不丢失的前提下，把几 TB 甚至几十 TB 的数据从老系统搬到新系统。这背后是无数次的演练、回滚、修复，还有那些凌晨三点的咖啡和屏幕前模糊的眼睛。每次迁移成功，我都觉得像打完一场硬仗，但下次迁移前，仍然会失眠、焦虑。可能这就是这行的宿命——你永远不知道下一个坑在哪儿，但你知道它一定会出现。
