数据库回滚策略是什么
数据库没有一键回滚：数据被改写、删除后，逆向操作是否可行取决于有没有备份、有没有双写与闪回手段。策略以向前兼容为目标——扩展加字段、双写回填、切换读取、最后收缩清理；变更与应用发布解耦，任何一步都能单独停下观察。回退脚本、备份与闪回能力都提前准备并演练，而不是事故发生时才找。
基本信息
| 常用路径 | 扩展（加字段或表）→ 双写与回填 → 切换读取 → 收缩（清理旧结构） |
|---|---|
| 回退脚本 | 每次迁移准备 down 脚本并演练 |
| 数据修复 | DML 失误用备份或闪回，先冻结写入再处理 |
| 验证 | 回滚后跑数据一致性校验 |
| 前置条件 | 备份可恢复性定期验证，闪回窗口（binlog 保留期）要清楚 |
不同失误的恢复手段
| 场景 | 手段 | 前提 |
|---|---|---|
| 误删少量行 | 闪回或 binlog 回放 | binlog 保留期与权限可用 |
| 结构不兼容 | 向前修复或切回旧结构 | 双兼容窗口内 |
| 整表误删或损坏 | 从备份恢复并补齐增量 | 备份与补齐链路可用 |
| 数据被污染 | 定点恢复或重放修正脚本 | 污染范围可定位 |
典型使用场景
- 结构变更发布：按扩展收缩节奏推进，每步保留回退点
- DML 失误处置：先冻结写入、定位影响行，再选闪回或修正脚本
- 大版本回滚：应用回滚而库保留新结构（双兼容设计兜底）
- 恢复演练：季度级演练验证备份与恢复时长
- 审计留痕：所有修复操作留档，事后复盘流程改进
扩展与收缩的版本节奏
扩展与收缩的版本节奏
V1 加可空字段 旧代码不受影响
V2 回填并双写
V3 读取切换到新字段
V4 删除旧字段（确认无回退需求后）破坏性变更（DROP、TRUNCATE）前必须确认备份完成且可恢复，并安排在收缩阶段后期执行。
回滚窗口是设计产物：旧结构保留多久、binlog 留多久，决定你能退多远，写进架构决策而非默认值。