Sequelize生产环境执行Schema与数据迁移的风险与注意事项

一、方案各环节的注意事项 #

1. 新增列与外键约束环节 #

• 若操作的是大表，新增外键时数据库会全表扫描验证关联数据，大概率触发表级锁，建议拆分操作：先新增允许为空的列，再单独创建外键约束，且尽量在业务低峰期执行。
• 必须同步确认关联表的对应字段已建立索引，否则外键关联会导致后续查询/更新性能急剧下降。
• 新增列后，要临时限制应用代码向该列写入空值（比如在业务逻辑层加校验），避免后续填充数据期间出现新的空值记录。

2. 批量数据填充环节 #

• 不要用单个大事务包裹全量更新：大事务会长时间占用锁资源，还会生成海量事务日志，极易触发数据库性能瓶颈甚至宕机。建议分批次处理，比如每次更新100-1000条记录，每批次用独立小事务，批次间隔加1-2秒休眠，降低数据库负载。
• 批量查询必须分页：避免一次性加载全表数据到内存引发OOM，优先用基于主键范围的分页（比如WHERE id > last_id LIMIT size），性能比LIMIT offset, size更优。
• 确保更新语句有合适的索引：如果更新条件无索引，InnoDB会退化为表锁，直接阻塞所有读写请求。
• 脚本要加幂等逻辑：比如更新前先判断该列是否已填充，避免重复执行时覆盖数据或引发错误；同时记录每批次的处理日志，失败时能快速定位断点重试。

3. 添加非空约束环节 #

• 加约束前必须做全表校验：用SELECT COUNT(*) FROM table WHERE new_column IS NULL确认所有记录已填充有效值，避免因存在空值导致约束创建失败，且失败过程中会锁表。
• 大表加非空约束不要直接用ALTER TABLE：原生DDL会全表扫描并锁表，建议用在线DDL工具（如pt-online-schema-change、gh-ost）实现无锁改表。
• 必须在业务低峰期执行，且提前通知运维团队监控数据库状态。

二、上线后可能的严重生产影响 #

• 服务大面积不可用：若新增外键、批量更新或加约束时触发表锁，所有针对该表的读写请求都会被阻塞，超时后引发大量报错，甚至导致服务雪崩。
• 数据库资源耗尽：全量更新或大事务会瞬间拉高CPU、磁盘IO、连接数，导致数据库无法处理其他业务请求，严重时直接宕机。
• 事务日志溢出：大事务生成的redo/undo日志超过数据库配置的日志文件大小，会导致数据库停止响应，恢复时间可能长达数小时。
• 数据不一致：若填充脚本中途失败且无幂等处理，会出现部分记录已更新、部分未更新的情况，后续加非空约束失败，手动修复极易引入新的错误。
• 应用兼容性故障：填充数据期间，若应用代码未兼容新列的空值场景，会出现空指针异常、关联查询失败等业务逻辑错误，影响用户体验。

内容的提问来源于stack exchange，提问作者egremont of yorke