LLM 生成数据库迁移脚本从 schema 变更到可回滚实践一、迁移脚本的隐形风险加个字段、改个类型看起来小事一桩。手写迁移 SQL稍漏一句线上数据就乱。更怕的是能前进不能后退出问题无法回滚。迁移脚本和一般代码不同它直接动生产数据。错一步代价是丢数据、锁表、服务中断。这类脚本容错率极低。大模型擅长按 schema 差异生成迁移。但它必须懂数据安全的约束先备份思路、加锁策略、回滚语句。本文探讨用 LLM 生成可回滚的迁移脚本。二、迁移生成的机制迁移生成分三步diff、生成、校验。diff 段比对新旧 schema列出变更点。生成段为每点产出正向 反向两条语句。校验段检查是否有破坏性的隐式操作如丢列无备份。关键是成对产出。每条 forward 都配一条 backward。这样任何迁移都可撤销而非单行道。下面是生成的链路flowchart TD A[旧 schema] -- B[diff 变更点] C[新 schema] -- B B -- D[生成 forward SQL] B -- E[生成 backward SQL] D -- F[校验: 含锁/备份策略] E -- F F -- G{安全?} G --|是| H[产出可回滚迁移] G --|否| I[提示人工补全] style H fill:#e8f5e9 style I fill:#ffebee关键在破坏性操作拦截。删列、改类型这类不可逆操作必须显式确认。绝不能模型默认可执行。三、生产级实现下面用代码描述迁移的生成与校验骨架。from dataclasses import dataclass from typing import Optional dataclass class Migration: name: str forward: str backward: str destructive: bool False DESTRUCTIVE_HINTS [DROP, DELETE, ALTER ... TYPE] def guard(m: Migration) - Migration: 标记破坏性操作强制人工确认而非自动执行 upper m.forward.upper() m.destructive any(h.split()[0] in upper for h in DESTRUCTIVE_HINTS) return m def emit(m: Migration) - str: if m.destructive: # 破坏性迁移必须带备份与回滚且不自动跑 return f-- 需人工确认(破坏性)\n-- 前置: 全量备份\n{m.forward}\n\n-- 回滚:\n{m.backward}\n return f{m.forward}\n\n-- 回滚:\n{m.backward}\n if __name__ __main__: m Migration(add_email, ALTER TABLE users ADD email TEXT;, ALTER TABLE users DROP email;) print(emit(guard(m)))真实流程会先 dry-run 在影子库。并用事务包裹失败整体回滚。大表变更改用在线 DDL避免长锁。四、LLM 生成数据库迁移脚本的代价与边界LLM 生成迁移高效但安全红线不能碰。不可逆操作的绝对谨慎。DROP/类型变更一旦执行难挽回。必须人工确认 前置备份 回滚语句三件套。模型可生成不可自动批准。大表锁表风险。ALTER 大表会长时间锁阻塞业务。应识别表规模改用 pt-online-schema-change 类工具。生成脚本要区分小表直接改与大表在线改。数据回填的正确性。加非空列要补默认值或回填。模型易漏历史数据怎么填这一步。生成时要显式问清回填策略。环境差异。开发库结构与生产可能不一致。生成应基于生产 schema 的快照而非本地。否则迁移在生产跑出未预期错误。迁移生成的环境一致性是隐形雷区。开发库结构与生产往往不同步基于本地 schema 生成的迁移在生产跑可能引用了不存在的表或字段。建议生成前先拉取生产 schema 快照作为事实来源而非信任本地。另一个实践是预演机制迁移先在影子库或副本库完整跑一遍 forwardbackward确认可逆且无误再上生产。最后大表迁移要避开业务高峰用在线 DDL 工具在流量低峰执行并把锁时长作为审批硬指标超过阈值必须改方案不能拿业务可用性赌。五、总结用 LLM 生成迁移脚本本质是用成对回滚换数据安全。机制上 diff 产出 forward/backward破坏性操作强制人工。工程上 dry-run 影子库、在线 DDL 控锁、基于生产 schema。落地路线先 diff 出变更点成对生成正反语句标记破坏性并前置备份大表走在线变更。迁移能前进也能后退线上才敢动。