数据库迁移方案少问三个问题，回滚要多花两天

做数据库迁移最怕的不是慢，是不可回滚。我们做过一次分库迁移，前期方案讨论了两周，上线用了四个小时，但真正花时间的是上线后第三天的回滚——花了两天，还丢了部分增量数据。复盘下来问题出在方案设计阶段少问了三个问题。第一个问题：回滚时点的数据怎么办。迁移期间新旧两套都在写，回滚意味着把新库这几天的增量同步回旧库，同步逻辑如果不提前写，回滚时就只能手工修数据。正确做法是迁移方案必须包含反向同步脚本，并且在上线前演练一次。第二个问题：哪些查询是双写的，哪些是单边的。如果只有部分表双写，回滚时那些单边写的数据就是空的，业务会立刻出问题。方案里必须列出全部写路径，逐个标注双写还是单边。第三个问题：判定回滚的阈值是什么。我们当时没有明确指标，靠人感觉，结果在继续和回滚之间犹豫了很久，白白放大了数据差异。正确做法是提前定好三个数字，比如错误率超过百分之五、延迟超过两秒、持续十分钟，达到即触发回滚，不需要开会决定。这次之后我们把迁移方案模板重写了，强制包含四部分：正向流程、反向流程、双写清单、回滚触发条件。后来又做过两次迁移，都在一小时窗口内完成，其中一次真的按预设阈值回滚了，二十五分钟恢复，没有数据损失。