以新增规范化字段并回填为例，生成成对的迁移与回滚脚本，用前后校验、事务演练和备份验证控制数据库变更风险，适合需要可复现流程与人工复核的团队直接照做。
任务与最终结果
本例要为用户表新增一个规范化名称字段，用现有 display_name 回填，再为后续查询建立约束或索引。最终结果不是两段孤立 SQL，而是向前迁移、回滚脚本、迁移前后校验查询、不可逆性说明和测试副本演练记录。
| 前置条件 | 必须确认 | 禁止事项 |
|---|---|---|
| 测试环境 | 结构和数据分布接近生产的副本 | 首次在生产执行生成脚本 |
| 恢复能力 | 完整备份且恢复流程可用 | 只确认备份文件存在 |
| 数据语义 | 区分可逆与不可逆变换 | 假设 DROP 后数据仍可恢复 |
| 权限 | 最小迁移权限和审批流程 | 把生产凭据交给模型 |
先定义什么叫成功回滚
PostgreSQL 的数据定义文档可用于核对表、列、约束等 DDL 概念。是否能把全部操作放在同一事务、会获取何种锁以及索引操作如何执行，仍要按目标数据库版本和实际语句确认。
把数据库上下文完整提供给 AI
只说“给 users 表加一列”不足以生成安全脚本。应提供脱敏后的表结构、数据量级范围、空值比例、唯一性要求、应用发布顺序、允许锁定时间、迁移工具和回滚窗口。OpenAI 的提示工程指南可用于组织清晰指令、上下文与输出格式，但生成结果仍需数据库维护者验证。
目标数据库：PostgreSQL，具体版本由执行者填写并核对。
任务：为 users 表新增 display_name_normalized，并从 display_name 回填。
约束：不得修改原字段；空值保持空值；转换规则必须由人工填写；先在测试副本演练。
请输出：
1. 迁移前检查查询；
2. 向前脚本，按 DDL、分批回填、约束或索引分段；
3. 回滚脚本；
4. 每段后的校验查询；
5. 锁、事务、磁盘、复制延迟与不可逆风险；
6. 需要人工确认的数据库方言差异。
不要编造表规模、执行时间或“零停机”结果。生成成对脚本与校验查询
下面是结构示意，转换函数、批次方式和索引策略必须由项目人员替换。大表一次性 UPDATE 可能产生长事务、锁、日志和复制压力，因此不应因为 AI 给出单条语句就直接执行。
BEGIN;
ALTER TABLE users ADD COLUMN display_name_normalized text;
COMMIT;
UPDATE users
SET display_name_normalized = lower(trim(display_name))
WHERE display_name IS NOT NULL
AND display_name_normalized IS NULL;
SELECT count(*) AS missing_rows
FROM users
WHERE display_name IS NOT NULL
AND display_name_normalized IS NULL;
SELECT count(*) AS unexpected_rows
FROM users
WHERE display_name IS NULL
AND display_name_normalized IS NOT NULL;
-- 回滚结构；执行前确认应用已停止读取新字段
BEGIN;
ALTER TABLE users DROP COLUMN display_name_normalized;
COMMIT;lower(trim(...))只是演示转换，可能受排序规则、Unicode、语言和业务语义影响。名称规范化尤其不能只凭技术直觉决定。若回填值需要保留，则回滚前应导出对应主键和值，或采用影子表、审计表等经评审的恢复设计。
在测试副本完成两轮演练
- 建立基线：记录行数、空值、重复值、关键约束、索引、样本校验和及数据库可用空间。
- 执行向前迁移：逐段运行并记录开始时间、结束状态、受影响行数、锁等待、日志增长和复制延迟，不自行声称耗时可接受。
- 验证应用：使用兼容旧结构和新结构的应用版本执行读写测试，确认发布顺序不会访问尚未存在或已经删除的字段。
- 执行回滚：按预定顺序停止新字段写入、回退应用、保存必要数据，再运行回滚脚本。
- 比较基线：检查原字段、行数、约束、索引和业务查询结果；仅“SQL 没报错”不代表恢复成功。
- 再演练一次：从干净副本重复全过程，确认脚本没有依赖第一次运行留下的状态。
失败诊断
| 现象 | 常见原因 | 处理方法 |
|---|---|---|
| 回填长时间阻塞 | 全表更新、锁竞争或批次过大 | 停止并按主键范围设计可恢复批次 |
| 重复执行时报列已存在 | 脚本缺少状态检查或迁移记录异常 | 先查真实结构，不盲目补条件绕过 |
| 回滚后应用报错 | 应用仍读取新字段 | 按兼容发布顺序先回退应用 |
| 校验行数正确但内容错误 | 转换规则、排序规则或空白处理有误 | 增加样本级和分组校验 |
| 事务不能覆盖全部步骤 | 数据库方言或在线操作限制 | 拆分阶段并设计失败后的恢复点 |
安全、隐私与人工复核
OWASP Top 10 用于提示应用安全风险范围，详见 OWASP Top Ten 项目。迁移脚本不应拼接来自用户或不可信文件的标识符和值；执行入口、迁移权限和审计记录也需要保护。该来源不能证明某段 SQL 自动安全，仍需结合数据库和应用威胁模型审查。
- 把表结构和样本提交给 AI 前移除真实姓名、邮箱、令牌、客户标识和内部连接信息。
- 人工确认转换是否可逆、回滚会丢失什么、备份是否真正可恢复，以及业务是否接受维护窗口。
- 审查 AI 生成代码的版权与项目贡献规则，不复制来源不明的大段迁移脚本。
- 成本包括模型调用、测试副本、备份存储、数据库日志、复制流量、锁等待和工程值守。
- 任何生产执行都应经过代码评审、变更审批、监控准备和明确的停止条件。
结论
AI SQL 迁移回滚的正确用法，是让模型帮助补齐成对脚本、校验问题和失败分支，而不是授权它决定生产变更。只有可逆性已定义、测试副本完成两轮演练、应用发布顺序明确且备份恢复可验证，脚本才具备进入变更流程的条件。
常见问题
所有 SQL 数据迁移都能编写回滚脚本吗？
不能。删除原值、合并记录或执行不可逆转换后，反向 SQL 可能无法恢复信息，需要备份、影子表、审计记录或向前修复方案。
迁移脚本放进事务就一定安全吗？
不一定。事务性 DDL、锁行为和在线索引能力取决于数据库与具体语句，长事务还可能放大日志、复制和并发压力。
AI 生成的校验查询应检查什么？
至少检查行数、空值、重复值、转换结果、约束、索引、异常样本和关键业务查询，并把迁移前、迁移后及回滚后的结果进行对照。