别让AI写数据库迁移脚本：一个命令可能让你的服务凌晨3点宕机

LLM随手可得的时代让我们效率倍增，但也让我们危险地放松警惕。我们正在目睹一种转变：开发者把关键基础设施决策交给生成式模型。让AI建议一个React组件或正则表达式，风险相对可控；但让它决定数据库架构变更，就是在玩火。

问题不在于AI"不擅长"SQL，而在于AI缺乏上下文。它不知道你的流量模式，不理解你的锁机制，更不会在乎凌晨3点因为一个持续十分钟的表锁导致生产环境全黑时，你是不是正在被老板打电话叫醒。

当你让AI生成迁移脚本——比如给一张500万行的表加个带默认值的非空列——它给出的代码语法上很可能完美无缺。你在本地环境用50条种子数据跑一遍，毫秒级完成。

问题出现在同样的脚本进入生产环境时。

AI生成的标准写法：

-- AI生成：简洁、干净，且可能灾难性
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255) NOT NULL DEFAULT 'pending';

在大表上，这个操作可能触发全表重写。以PostgreSQL为例，11之前的版本会在把默认值写入每一行时锁定整张表。如果你的应用流量很高，API开始抛出504网关超时，因为所有连接都在等那把锁释放。

人工设计的安全迁移：

-- 第一步：先加可空列（瞬间完成）
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255);

-- 第二步：给未来行设默认值
ALTER TABLE orders ALTER COLUMN status_code SET DEFAULT 'pending';

-- 第三步：分批更新现有数据

2017年GitLab的宕机事故已经证明过数据库状态的脆弱性。更近的案例里，几家初创公司报告了"静默"数据损坏——AI建议把INT改成BIGINT，却没考虑ORM在滚动部署期间怎么处理类型转换。如果AI写的迁移在新代码全量部署前就删了列，你的应用会直接崩溃。

语法正确不等于操作安全。AI能帮你写代码，但扛不住凌晨3点的on-call，也不懂你的业务在什么时候最不能掉链子。