名称

数据库迁移脚本评审

描述

当需要评审数据库迁移脚本或设计零停机表结构变更时使用。该技能逐条检查锁表风险、执行时长、回填方案、索引策略、回滚路径与数据兼容性，并针对 MySQL 与 PostgreSQL 给出可执行的改写建议。适用于上线前 DDL 评审、大表改造、分库分表迁移和多环境发布。关键词：数据库迁移、DDL、锁表、在线DDL、大表变更、回填、回滚、索引创建、MySQL、PostgreSQL、零停机、数据兼容、迁移脚本评审、gh-ost、pt-online-schema-change。

数据库迁移脚本评审

把一份 DDL/回填脚本审到“能在生产高峰安全执行”，而不是“在测试库跑通过”。

何时使用

上线评审中有 ALTER TABLE、CREATE INDEX、数据回填。
表行数超过百万，或表被高频读写。
需要制定回滚方案与分批执行计划。
分库分表、字段拆分、编码变更等结构性调整。

不适用：纯查询优化、无结构变更的索引重建（可复用检查清单）。

输入

迁移脚本全文与目标数据库版本。
表的行数、日均增长、读写 QPS、主从延迟容忍度。
发布窗口与是否可停写。
应用侧是否与迁移同时发布。

行数未知时按“大表”处理，因为乐观假设的代价是一次生产事故。

工作流

第 1 步：语句分类

把脚本拆成独立语句，逐条标注：

类型	示例	风险点
元数据变更	加可空列、改默认值	版本差异大
表重建	改列类型、改字符集	长时间锁或拷贝
索引变更	加索引、删索引	写放大、锁
数据回填	UPDATE 全表	长事务、主从延迟
约束变更	加外键、加唯一键	校验全表、失败回滚

第 2 步：锁与时长评估

按 references/lock-matrix.md 对照目标版本判断：

MySQL 8.0 加列通常是 INSTANT（即时），但改列顺序、改字符集仍会重建表。
PostgreSQL 11+ 加带默认值的列不重写表；加约束需 NOT VALID（未验证）再验证。
大表建索引优先使用在线工具或并发建索引。

给出量级估算：行数 × 单行成本 ÷ 磁盘吞吐，并注明这是数量级而非精确值。

第 3 步：回填设计

回填必须满足四条：

分批：按主键区间，每批 1000 到 5000 行，批间休眠。
幂等：重复执行结果一致，用 WHERE new_col IS NULL 之类的条件收口。
可观测：每批输出影响行数与耗时，连续多批为 0 即结束。
可暂停：通过开关或脚本参数随时停止，不依赖杀进程。

禁止单条 UPDATE 覆盖全表。

第 4 步：兼容性

按“先加后删”推进：

加新列/新表（可空，带默认）。
应用双写。
回填历史数据。
校验一致性。
切换读路径。
观察一个发布周期后再删旧列。

每一步都可独立回滚，且旧版本应用在新结构上仍能运行。

第 5 步：回滚与演练

DDL 回滚脚本必须与正向脚本成对提交。
删列、改类型的回滚通常不可逆，需要备份表或逻辑导出。
在预发环境用生产量级数据演练一次，记录实际耗时。

检查清单

[ ] 每条语句都标注了锁类型与预计耗时。
[ ] 大表操作有分批方案与暂停手段。
[ ] 新增列可空或有安全默认值，旧应用不受影响。
[ ] 索引创建未阻塞写入，或安排在低峰并限速。
[ ] 外键与唯一约束先建后验，避免全表长锁。
[ ] 回填幂等，可重复执行。
[ ] 回滚脚本已准备，删列类变更已备份。
[ ] 主从延迟监控与熔断阈值已配置。
[ ] 迁移与应用发布顺序明确，不存在中间态读不到数据。
[ ] 字符集与排序规则变更已评估索引重建成本。

输出模板

## 结论
可在低峰执行 / 需改造后执行 / 禁止直接执行

## 逐条评审
| # | 语句 | 类型 | 锁 | 预计耗时 | 风险 | 建议 |
| --- | --- | --- | --- | --- | --- | --- |

## 执行计划
1. 预检查 ...
2. 分批回填 ...
3. 切换 ...

## 回滚方案
...

## 监控
- 主从延迟 > X 秒 暂停
- 锁等待 > Y 秒 告警

反模式

在业务高峰直接对千万级表 ALTER。
用一条 UPDATE 回填，产生小时级长事务。
先删旧列再改应用，回滚时数据已丢。
加唯一索引不先清理重复数据，迁移中断。
只测空库，不测存量数据。

参考文件

references/lock-matrix.md：MySQL / PostgreSQL 常见 DDL 的锁行为。
references/zero-downtime-patterns.md：扩展-回填-切换的标准流程。