AI 生成迁移脚本DDL 之前先问能不能回滚一、迁移脚本不是能执行就算正确AI 可以快速生成建表、改字段、补索引和数据回填脚本这对日常研发很有帮助。但数据库迁移的风险不在脚本是否能跑通而在锁表、回滚、数据兼容、主从延迟和业务读写路径。一个语法正确的 DDL如果在高峰期锁住大表就是事故。因此 AI 生成迁移脚本只能作为初稿。上线前必须经过数据库规范检查、影响评估、回滚设计和灰度执行。迁移脚本要回答三个问题执行时会不会阻塞业务执行失败后如何恢复旧版本代码和新版本代码是否都能兼容中间状态。二、迁移流程从脚本到上线需要多道闸flowchart TD A[AI 生成脚本] -- B[SQL 规范检查] B -- C[锁与成本评估] C -- D[兼容性评审] D -- E[预发执行] E -- F[分批灰度] F -- G[结果校验] G -- H[正式完成]常见危险操作包括大表直接加非空字段、修改字段类型、删除字段、重建大索引、一次性回填全表、无 where 条件更新和长事务批处理。AI 可能不会知道表有多大也不知道当前数据库版本对在线 DDL 的支持程度。脚本必须结合元数据和生产约束重新评估。兼容性是迁移设计的核心。安全做法通常是扩展式变更先新增字段双写或回填验证数据一致再切读路径最后删除旧字段。不要让代码发布和 DDL 强绑定在同一瞬间否则任何一步失败都会难以回滚。三、检查配置把危险规则写出来下面是一份简化的迁移审查规则。它可以作为 AI 自检输入也可以接入 CI。migration_guard: forbid: - drop column without deprecation window - update table without where condition - alter large table during peak hours require: - rollback_plan - estimated_rows - lock_impact - precheck_sql - postcheck_sqlAI 生成脚本后可以要求它同时生成预检查 SQL 和后检查 SQL。预检查用于确认数据分布、空值比例、重复键和表大小后检查用于确认回填数量、校验和、索引可用性和业务查询计划。只给 DDL 不给检查语句脚本不完整。对于数据回填要分批执行。每批限定主键范围或时间范围控制事务大小和睡眠间隔观察主从延迟和锁等待。回填任务应支持断点续跑而不是失败后从头再来。数据库迁移里耐心比速度便宜。四、回滚设计有些 DDL 不能假装可逆回滚不是简单写一个反向脚本。删除字段后数据丢失字段类型缩窄后精度可能不可恢复索引删除后重建需要时间。迁移方案必须区分逻辑回滚和物理回滚。很多时候真正安全的做法是先保留旧结构等观察期结束再清理。上线窗口也要明确。执行人、审批人、监控指标、暂停条件和回滚步骤都应写在迁移单里。AI 可以帮忙生成清单但不能替你承担生产风险。数据库迁移没有“应该没事”只有“验证过这些条件”。最后要保留执行日志。每批执行时间、影响行数、错误信息、主从延迟和校验结果都应记录。等事故发生后再想找证据通常只剩慢日志和沉默。五、总结AI 生成数据库迁移脚本可以提高起草效率但 DDL 上线必须经过规范检查、锁评估、兼容性设计、分批执行和回滚规划。能执行不代表能上线能上线也不代表能安全回滚。数据库变更要慢一点数据才会稳一点。