迁移安全检查器

检查数据库迁移是否存在数据丢失风险、表级锁操作、向后兼容性问题以及部署顺序问题。支持原生 SQL 迁移、各类 ORM（Prisma、Drizzle、Django、Rails、Sequelize、TypeORM）以及迁移工具（Flyway、Liquibase、golang-migrate）。

使用方式

"检查此迁移是否安全"
"该迁移是否会锁定 users 表？"
"该迁移是否向后兼容？"
"在部署前审查待处理的迁移"

工作原理

1. 迁移文件发现

find . -path "*/migrations/*.sql" -o -path "*/migrations/*.py" -o -path "*/migrate/*.sql" 2>/dev/null | head -20
ls prisma/migrations/*/migration.sql 2>/dev/null
find . -path "*/migrations/0*.py" 2>/dev/null | tail -10
ls db/migrate/*.rb 2>/dev/null | tail -10

2. 危险操作检测

数据丢失风险：

• DROP TABLE / DROP COLUMN — 不可逆的数据删除
• TRUNCATE TABLE — 清空全部行
• 列类型收窄（例如 VARCHAR(255) → VARCHAR(50)）
• 移除 NOT NULL 约束但未提供默认值（已有行将被设为 NULL）
• 重命名列（破坏现有查询）

锁表操作（针对大表）：

• ALTER TABLE ... ADD COLUMN 带 DEFAULT 子句（PostgreSQL 11 之前版本、MySQL）
• ALTER TABLE ... ADD INDEX 且未使用 CONCURRENTLY
• ALTER TABLE ... MODIFY COLUMN（MySQL 全表重写）
• CREATE INDEX 且未使用 CONCURRENTLY（PostgreSQL）
• ALTER TABLE ... ADD CONSTRAINT（触发全表扫描）

向后兼容性：

• 新增 NOT NULL 列但未指定默认值
• 重命名表或列
• 移除枚举值
• 修改主键
• 删除查询所依赖的索引

3. 部署安全性

滚动部署兼容性：

• 旧代码能否在新 schema 下正常运行？（向后兼容）
• 新代码能否在旧 schema 下正常运行？（向前兼容）
• 该迁移是否需分多步部署？

高风险变更的安全模式：

步骤 1：添加新列（允许 NULL）
步骤 2：部署同时向新旧两列写入的代码
步骤 3：回填历史数据
步骤 4：部署仅从新列读取的代码
步骤 5：删除旧列

4. 性能影响评估

• 估算表大小及锁持续时间
• 判断迁移是否可在业务高峰期执行
• 如需，建议安排维护窗口
• 推荐并发/在线迁移替代方案

5. ORM 特定检查项

• Prisma： 使用 prisma migrate diff 检测破坏性变更
• Django： RunPython 操作未定义 reverse 函数
• Rails： 不可逆迁移
• Sequelize： queryInterface.removeColumn 未做数据备份

输出示例

## 迁移安全报告

**已审查迁移：** 3 个待处理迁移  
**数据库：** PostgreSQL 15  

### 迁移 1：20260430_add_preferences.sql  
✅ 安全 — 新增可空列，无锁表行为  

### 迁移 2：20260430_add_email_unique.sql  
🟠 注意 — 在含 200 万行的表上添加唯一约束  
锁持续时间：15–30 秒｜创建期间阻塞写入  
修复建议：使用 CREATE UNIQUE INDEX CONCURRENTLY + ADD CONSTRAINT USING INDEX  

### 迁移 3：20260430_remove_legacy_columns.sql  
🔴 危险 — 删除 3 个含 50 万非空值的列  
1. 确认无任何代码引用这些列  
2. 删除前备份数据  
3. 应与代码变更分离部署  

| 迁移文件 | 安全等级 | 锁风险 | 向后兼容 |
|-----------|----------|--------|------------|
| add_preferences | ✅ | 无 | 是 |
| add_email_unique | 🟠 | 15–30 秒 | 是 |
| remove_legacy | 🔴 | 极低 | 否 |