AI生成的数据库迁移脚本怎么验收？从备份、事务到回滚演练的实用指南

先明确验收对象：结构变更还是数据迁移

AI生成的迁移脚本应被当作一项待审查的数据库变更，而不是可以直接上线的最终答案。验收第一步，是把脚本拆成结构变更和数据迁移两类。结构变更包括新增或删除表、字段、索引和约束；数据迁移则包括字段转换、批量更新、数据清洗和历史记录补写。两类操作的风险、执行时长和回滚难度并不相同。

• 逐条核对脚本涉及的数据库、表、字段、索引和约束，确认没有超出工单范围。
• 检查查询条件和数据范围，尤其关注无条件更新、删除语句以及可能重复执行的操作。
• 确认字段类型、默认值、字符集、精度和空值规则与应用代码及业务数据一致。
• 为每个步骤记录预期影响行数，执行前先用查询语句统计待处理数据。

执行前：先验证备份和恢复能力

备份不是执行迁移前勾选一个选项就算完成。应确认备份覆盖目标数据库和相关对象，并在隔离环境实际恢复一份，检查表结构、关键数据和应用连接是否可用。恢复演练还要记录大致耗时，以及从备份恢复到可接受状态需要哪些操作。只有知道备份能否恢复、恢复需要多久，回滚方案才有现实依据。

测试或预发布环境应尽量使用接近生产规模和分布的脱敏数据。先执行完整迁移，再验证应用读写、关键查询、索引命中情况和数据数量变化。测试环境通过只能说明已覆盖的条件下未发现问题，不能等同于生产环境绝对安全；生产数据量、并发请求、权限和硬件条件都可能不同。

执行中：检查事务、锁和执行顺序

不要默认所有迁移都能放在同一个事务中完成。事务支持取决于数据库类型、具体操作和配置，某些DDL操作可能有特殊限制、隐式提交或较长的锁持有时间。应查阅目标数据库对应版本的官方文档，并在相近环境中实测，而不是仅根据脚本表面的BEGIN和COMMIT判断安全性。

• 确认每一步的前置条件，例如先增加可为空字段，再部署能够写入新字段的应用。
• 评估索引创建、字段重建和批量更新对锁、CPU、磁盘和日志空间的影响。
• 为长时间数据处理设置分批策略，记录每批范围和已完成进度，避免一次性扫描或更新大表。
• 安排低峰期执行，并准备监控数据库连接数、锁等待、执行耗时、错误日志和磁盘空间。
• 明确失败后的处理方式：是停止并保留现场，还是跳过已完成批次继续执行。

实用案例：新增非空字段的分阶段迁移

例如业务表需要新增一个非空字段，不宜直接创建字段并要求旧数据立即满足约束。更稳妥的验收方案通常是：第一阶段新增可为空字段和必要索引；第二阶段发布兼容代码，让新旧版本都能工作；第三阶段分批回填历史数据，并核对每批成功数量和异常记录；第四阶段在确认没有空值后，再根据目标数据库的行为设置非空约束。每个阶段都要有明确的检查结果和停止条件。

执行后：用数据和业务结果完成验收

迁移结束后，应同时核对结构和数据。结构方面检查字段、约束、索引及默认值是否符合设计；数据方面比较迁移前后的总量、分组统计、空值数量和关键业务样本。随后执行核心读写流程，确认应用没有出现类型不匹配、超时、重复写入或权限错误。对于涉及金额、状态、关联关系的数据，还应采用业务可解释的抽样规则，而不是只看脚本返回成功。

回滚必须演练，不能只写在文档里

回滚方案应针对每一步具体设计。新增字段通常可以保留或删除，但已经完成的数据转换、覆盖写入和删除操作未必能够自动逆向。若原值被覆盖，应提前保留备份列、变更记录或可恢复副本；若迁移不可逆，则应采用备份恢复、补偿脚本或切换旧版本数据等方案，并明确触发条件。

最终验收记录至少包括脚本版本、目标环境、执行人、开始和结束时间、影响行数、错误信息、备份位置、恢复结果、监控截图或日志，以及回滚演练结论。只有当范围、风险、验证证据和失败处理都清楚时，AI生成的脚本才具备进入生产变更流程的基础。