down 脚本是什么
为结构变更编写回退脚本（如 Liquibase rollback、Rails db:rollback、Flyway 的 Undo 能力），同时明确边界：已删除的数据无法靠结构回退恢复。down 脚本与 up 一并评审入库，并在影子库演练；结构可回退，数据要靠备份。回退脚本是发布回滚方案的组成部分，而不是数据恢复手段，二者别混为一谈。
基本信息
| 工具形态 | Flyway（Undo）、Liquibase rollback、Rails db:rollback |
|---|---|
| 边界 | 结构可回退，已删除的数据不可回退 |
| 验证 | 在影子库演练 down 脚本 |
| 记录 | down 脚本与 up 一并评审入库 |
| 定位 | 发布回滚方案的一部分，不等于数据恢复 |
典型使用场景
- 结构回退：加列、建索引类变更的撤销
- 发布配套：回滚方案中结构部分的执行清单
- 演练：影子库跑 up 再跑 down，验证可逆
- 评审：与 up 脚本同仓同评审成对维护
- 事故处置：与扩展收缩模式配合降低回退依赖
- 归档：历史迁移的回退脚本按版本保留
迁移脚本成对示例
迁移脚本成对示例
-- V1__add_status.sql
ALTER TABLE orders ADD COLUMN status VARCHAR(16);
-- U1__add_status.sql（回退）
ALTER TABLE orders DROP COLUMN status; -- 列内数据随回退丢失可逆性读法
| 变更类型 | 可逆性 | 注意 |
|---|---|---|
| 加列 | 容易回退 | 回退会丢列内数据 |
| 建索引 | 容易回退 | 大表撤销注意耗时 |
| 删表删列 | 不可逆 | 靠备份而不是脚本 |
| 数据迁移 | 视方向而定 | 双向脚本都要评估 |
| 约束变更 | 通常可逆 | 先确认存量数据满足 |
down 脚本 DROP 刚写入数据的列或表：回退即数据丢失，必须先评估并备份。
先加后删思路：先加新结构、双写、再删旧结构，减小对回退脚本的依赖。
演练按真实量级：发布前在影子库用接近生产的数据量跑一遍回退。
回退耗时评估：大表结构撤销可能超过发布窗口本身，提前评估量级。
执行保障
- 权限控制：回退脚本执行权限单独管理，避免误触发