编程开发 编辑复核
数据库迁移安全计划
把 schema 变更拆成兼容写入、回填、切换、验证和回滚步骤，降低生产数据风险。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名数据库迁移工程师。请在不假设生产权限和数据规模的前提下设计分阶段迁移，优先保证旧代码和新代码能短期共存。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 现有 schema、读写路径和数据量假设
2. 扩展、回填、切换和收缩四阶段步骤
3. 锁表、索引、长事务和复制延迟风险
4. 分批回填、校验查询和停止条件
5. 回滚、备份、演练和发布后监控
输入变量：
- 结构变更（{{schema_change}}）：说明新增、重命名或删除的表字段。
- 流量与规模（{{traffic}}）：提供读写量、数据量和数据库版本。
- 应用路径（{{application}}）：说明读写代码、任务和旧客户端。
- 回滚边界（{{rollback}}）：说明可接受的回滚方式和窗口。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先在生产副本或演练环境验证执行时间和锁行为。
- 涉及删除数据或列时必须保留可恢复备份并由负责人确认。
WHEN IT FITS
适用判断
适合这些情况
- 迁移涉及多个步骤，需要理清执行顺序。
- 应用代码和表结构要协同变更，需要排出上线次序。
- 要给团队一份可执行的步骤清单。
换个做法更好
- 你更关心的是风险和回滚：用《数据库迁移安全计划》。
- 只是加一个可空字段：不需要计划。
- 你要做的是数据回填而非结构变更：用《数据回填运行手册》。
FAILURE MODES
常见翻车与修正
- 步骤顺序导致某个中间状态下应用会报错。
要求每一步后面写明「此时应用代码处于什么版本、能否正常工作」，有破损窗口的必须重排。
- 把结构变更和数据迁移混在同一步。
要求分开：先改结构，再迁数据，最后切换读写，每步独立可验证。
- 没说明每步执行完怎么确认成功。
补充要求：每步都给出验证查询或检查项，通过后才进行下一步。
ACCEPTANCE
怎么判断输出合格
- 每一步之后应用都能正常工作，没有破损窗口。
- 结构变更和数据迁移分开成独立步骤。
- 每步都有验证方式和通过标准。
- 标明了哪些步骤需要停机、哪些可以在线执行。
SAFETY BOUNDARY
使用边界
- 迁移会锁表并影响线上服务，大表操作前要评估锁时间并安排在低峰期。
- 每一步都要有对应的回滚步骤，不可回滚的操作（如删列）要单独拆到确认无误之后再做。