数据库变更进流水线：Flyway 的分级发布方案

数据库变更是发布链路里最谨慎的环节，手工执行 SQL 的时代结束后，我们把 Flyway 纳入流水线，跑了半年很稳。

目录结构按版本递增，命名规范 V 加版本号加双下划线加描述，Flyway 靠元数据表跟踪执行进度，幂等由不可变文件保证：已执行的脚本禁止修改，改了校验和就对不上，CI 会直接报错。

分级发布是重点设计。SQL 变更和代码变更分两条流水线，先发兼容性变更再发代码。以一个加表为例：

-- V112__add_coupon_table.sql
CREATE TABLE coupon (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  amount DECIMAL(10,2) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_user (user_id)
) ENGINE=InnoDB;

-- 兼容期代码同时处理新旧逻辑，数据回填后下个版本再清理

流水线里的执行策略：预发库自动执行，生产库生成执行计划进审批，DBA 确认锁风险后放行。大表变更强制走在线改表工具，Flyway 里包一层调用 gh-ost。

两个教训。一次脚本在预发执行成功但生产失败，原因是版本差异：预发 MySQL 8、生产 5.7，某个语法行为不同，从此评审要求标注数据库版本兼容性。另一次多人并行开发版本号冲突，规范改成日期加序号的格式，冲突消失。

现在数据库变更的审计、执行人、耗时全部自动记录。要说残余风险，是 Flyway 不做自动回滚，反向脚本要人工准备，这是它用简单性换来的代价，团队评估后接受了。

顺带一提数据库变更的窗口管理：批量脚本统一在低峰执行器排队，单实例同时只跑一个变更，避免锁竞争叠加。执行器的队列积压也有告警，防止变更积压到发版日集中爆炸，节奏感是数据库运维的关键词。

数据库变更流程跑稳后，又把只读实例的流量调度也纳入了管理：分析类查询默认走只读副本，变更窗口自动把副本切到延迟容忍模式，主库的压力曲线平了很多。数据库发布工程化的最终目标是让 DBA 从审批者变成架构顾问，把时间花在索引设计和容量规划上，而不是当人肉防火墙。