小型数据库迁移在发布前需要回滚说明

上个月，我差点把一次小型数据库迁移当作常规工作来处理。那只是添加一个可为空的列并回填几行数据，所以我计划在正常的部署窗口期间运行它。问题出现在预发布环境（staging）中，当时回填操作持有的锁时间比预期的要长，导致一个 API 路径开始超时。虽然没有发生严重的故障，但日志告诉我，如果在生产环境中面对真实流量，情况会变得很糟糕。 我停止了部署，并将变更重写为两个步骤。首先，我发布了不包含繁重更新的列。然后，我添加了一个批处理作业，按主键遍历行，每次处理 500 行，并在批次之间短暂休眠。我还写了一份回滚说明，内容不仅仅是"撤销提交"。它列出了需要关闭的功能标志（feature flag）、如何验证旧代码路径，以及哪条查询可以证明批处理没有触及目标集之外的行。 有用的经验是：迁移风险与文件中的代码行数无关，而是与锁、表大小、索引以及应用程序是否能同时运行新旧模式有关。现在，我要求在每个迁移…