一次数据库迁移，计划晚上八点开始，预计两小时。结果到凌晨四点还在对数，业务停了八小时。事后复盘，问题出在没做预演：生产数据量比测试环境大十倍，脚本根本跑不完。
方案要写清四件事
迁移范围和迁移方式与停服窗口以及回滚条件。这四项必须在动手前定下来并写进文档。范围不清就会边做边发现漏了表；方式没定好，做到一半想改路子。停服窗口要给足余量。
预估两小时就报四小时，因为总会有意外。宁可提前结束，也别让业务干等。给外部通知时也要按宽的那个时间说。别承诺"半小时搞定"。完整预演至少一次，用接近生产规模的数据在目标环境跑一遍。
预演是必须的
测三件事：脚本能不能跑完、耗时多少以及迁移后数据对不对。这三样心里有数，正式割接才不慌。数据校验要有量化标准。行数对不对、关键字段的汇总值一不一致和抽样比对是否吻合。只靠"看着差不多"是不行的。
写一段校验脚本，比人工抽查可靠得多。回滚要实际可执行：旧库保留多久、切回去要几步和需要谁配合。如果回滚要花四小时，那它就不是一个可用的回滚方案。目标应该是一小时内能切回来。割接当天要有人守着。
回滚方案不能只是想法
迁完不是结束，要盯至少一个业务高峰，看错误日志、看关键接口成功率跟看数据是否一致。有问题当场处理，别等第二天用户反馈。临了补一句：迁移的胜负在准备阶段。方案清、预演过与回滚可行，割接当天才能睡得着。谁来验收？这步能不能并行？
数据迁移的常见疑问
迁移要停服多久
按数据量和预演实测耗时评估，并留足余量。建议按预估时间的两倍对外通知。
必须做预演吗
建议必须。用接近生产规模的数据跑一遍，验证脚本可行性、耗时和数据正确性。
回滚要多久才算可用
一般建议控制在一小时内，超过这个时间对业务影响过大，方案需重新设计。
迁移前还要做一次容量评估。新环境的磁盘、内存跟连接数能不能撑住现有并发，这个不确认，迁完可能刚上线就跑不动，反而多一次故障。
还有一点别忘：迁移完成后老环境不要立刻销毁。保留一两周，确认新环境跑得稳再下线，中间发现问题还能对照。
总结：迁移靠准备取胜。范围清跟预演过和校验有标准与回滚可行，割接才稳。