干过几年做后端的人，谁没在数据库迁移上栽过跟头？凌晨两点，线上告警，业务表被锁死，回滚脚本跑了一半报错，新老字段对不上，数据乱成一锅粥。这种场面我见过不少，也修过不少。后来我慢慢摸索出门道，发现那些让人仰马翻的迁移事故，往往能在萌芽阶段就扼杀。今天不聊高深理论，聊聊我从混乱到平稳摸索出来的五个实在步骤。
第一步，把迁移当成一次需求评审，而不是随手写几段SQL就完事。很多人直接写ALTER TABLE，加字段、建索引，觉得改完就收工。其实真正的迁移脚本，核心在于弄清楚“现在是什么样”，以及“要变成什么样”。我见过最荒唐的事故，是同事把生产库里的订单状态字段从TINYINT改成VARCHAR，结果历史数据里的0和1全变成空串，前端直接崩溃。他根本没想过存量数据怎么处理。所以动手前，先把表结构、索引、外键关系、数据分布，甚至定时任务对这些表的依赖全捋一遍。列个清单，写清楚每个改动影响哪些上下游，再动笔。这一步花半天，后面能省下好几个通宵。
第二步，脚本要能分阶段执行，别指望一条语句干完所有事。很多人喜欢把加字段、回填数据、改索引、更新存储过程全塞进一个大事务。看着挺完整，可真跑起来，锁表时间动不动就是几十分钟，业务直接停摆。更麻烦的是，一旦中途报错，整个事务回滚，前面做的全白费，还得从头再来。我的做法是拆成多个小脚本：先加字段（允许为空），再分批回填数据，每批几百条或几千条，跑完一批停一下，观察负载，再跑下一批。才收紧约束、建索引。每个脚本独立成文件，能单独执行、单独回滚。这样即使某一步出问题，影响的也只是那一小段，不至于伤筋动骨。
第三步，回滚脚本不是事后补的，而是和主脚本一起写的。我见过太多团队，迁移脚本写得漂漂亮亮，回滚脚本却临时抱佛脚。真出事了，翻出备份手动改数据，越改越乱。正确做法是，每写一个主迁移脚本，旁边就放一个对应的回滚脚本，内容就是主脚本的逆操作。比如主脚本加了非空约束，回滚脚本就得把约束删掉，把数据恢复成可空状态。主脚本改了字段类型，回滚脚本就得把类型改回去，还得把回填的数据恢复原样。写回滚脚本时要提前想清楚哪些操作是不可逆的，要么提前备份数据，要么干脆别做那种操作。
第四步，预发环境跑通了不算数，得拿生产数据的“影子”来压测。很多团队在测试库上跑迁移，数据量就几万条，一切顺利，以为万事大吉。结果上生产，几千万行数据，一条UPDATE语句跑了一个多小时，锁表锁到业务超时。所以我的习惯是，从生产库拉一份脱敏数据的备份，或者至少把数据量级拉到和线上差不多，在预发环境模拟迁移。不光要看脚本能不能跑通，更要看耗时、锁等待、IO压力这些指标。如果某条语句在预发环境就要跑半小时，那到了线上只会更糟，得想办法优化SQL、加索引，或者进一步拆分批次。这一步虽然费时费力，但能避免上线时最尴尬的那种“脚本卡死，进退两难”。
第五步，也是很多人忽略的——迁移完成后，别急着收工，得做一次完整的数据校验和功能回归。脚本跑完，不代表迁移成功。新字段的值对不对？老数据有没有被正确回填？关联表的数据是否一致？这些都得用SQL去查，甚至写一些校验脚本，把迁移前后的数据做比对。我曾经做过一次分表迁移，把订单表按月份拆成12个子表。迁移完看了下数量，对得上，觉得没问题。结果第二天用户反馈，查不到三个月前的订单。一查才发现，有个子表的数据因为时间戳格式问题被漏迁了，数量恰好对不上是因为另一个表多迁了重复数据。从那以后，我每次迁移完都会写几条抽查SQL，专门挑边界值、空值、特殊字符数据来查。功能回归更是不能省，至少把核心链路走一遍，确认增删改查都正常，才敢跟老板说“完成”。
回过头来看，数据库迁移这事儿，本质上是在跟不确定性打交道。你永远不知道线上数据里藏着什么奇葩情况，某个字段有脏数据、某个外键指向了不存在的记录、某个历史数据的时间格式跟预想的不一样。所以那五个步骤，说到底就是让你在动手之前尽可能多地搞清楚状况，在动手之后尽可能快地发现问题、控制损失。别嫌麻烦，别图省事，每一步都扎实走完，你也能从那些让人头秃的通宵里解放出来。毕竟，平稳度过一次
