数据库变更的分步策略：先扩展，再切换

一次数据库变更可能同时影响正在运行的旧代码、即将部署的新代码和已有数据。把所有修改塞进一次发布，会让失败时很难判断该恢复代码还是恢复数据。

本篇目标： 用“便签增加摘要字段”的虚构例子，理解扩展、回填、切换、收缩四步法。

第一步，让新结构兼容旧读取

先增加允许为空的新字段，旧代码继续使用原字段，新代码能够识别新字段尚未填充的情况。新增结构是否会锁表、是否触发重写，取决于数据库版本、语句与数据规模，需要在相近环境里确认。

这个阶段不要急着删除旧字段或改变旧字段含义。让新旧代码能短暂共存，可以为后续验证留出空间。

第二步，小批量、可恢复地回填

回填应有明确的进度标记和重复执行策略。按稳定键分批处理，比一次扫描并更新所有数据更容易控制资源占用。处理每一批后，检查影响行数和异常记录，再继续下一批。

读取一批稳定 ID
  → 只更新仍未回填的记录
  → 提交并记录检查结果
  → 从上次边界继续

不要把“执行过脚本”当成“数据已经正确”。需要核对空值数量、代表性样本以及新旧逻辑之间的差异。

第三步，切换读取并观察

新读取可以先在受控范围启用，记录错误和差异。若允许双写，需要明确哪份数据是权威来源，以及一侧失败时如何处理，避免两套字段长期分叉。

读取切换成功后，也应保留一段能够回到旧读取的时间。具体长短由业务节奏决定，而不是一个固定数字。

第四步，最后再收缩

确认旧版本不再使用旧结构、恢复方案已经调整、数据验证通过后，才考虑删除旧字段或约束。破坏性变更通常应单独安排，不与第一次上线新读取混在一起。

迁移失败后，先核对真实结构与已提交的数据，再处理迁移工具的版本状态。把一个失败标记强行改成正常，不会自动完成未执行的语句。可用的备份和经过验证的恢复步骤，始终是变更前的基础准备。