1. 数据库迁移CI/CD工程导论

在传统开发模式中，数据库变更往往被视为“上线前的手工操作”：开发人员在本地写好 SQL，DBA 在发布窗口手工执行，出问题再回滚。这种方式在单体应用、低频发布时勉强可行，但当团队每天要发布多次、服务拆分成几十个微服务、数据库同时存在 MySQL、PostgreSQL、Redis 等多种引擎时，手工迁移就会成为交付链路上最脆弱的一环。数据库迁移 CI/CD 工程，正是把数据库结构变更（DDL）与数据变更（DML）纳入与代码同等的版本控制、自动化测试和流水线发布体系，使“数据库也能像代码一样持续交付”。

一、数据库迁移在 CI/CD 中的定位

要理解定位，先看一条典型的端到端交付链路。代码提交后，CI 流水线依次完成：拉取代码 → 编译构建 → 单元测试 → 集成测试 → 镜像打包 → 推送制品库；CD 阶段则完成：部署到预发 → 数据库迁移 → 应用发布 → 冒烟验证 → 灰度/全量。可以看到，数据库迁移是应用发布的前置依赖：新版本代码往往依赖新表、新字段或新索引，迁移未完成就发布应用，会直接导致运行时报错。

因此数据库迁移在 CI/CD 中承担三个角色：其一，它是版本化制品，每个迁移脚本都有唯一编号、校验和与执行记录；其二，它是流水线的一个阶段，有明确的准入与准出条件；其三，它是可回滚、可审计的变更单元，任何一次结构变化都能追溯到提交人、时间与关联需求。

二、核心挑战：为什么数据库迁移比代码发布更难

代码发布可以“重新部署一份新实例、切流量、旧实例销毁”，天然具备幂等与可回滚性；数据库迁移则直接作用于有状态的数据，难度体现在四个方面。

第一，不可逆变更。删除字段、收窄字段类型、删除表这类操作一旦执行，数据就永久丢失。例如把 VARCHAR(255) 改为 VARCHAR(50)，若已有数据超过 50 字符，迁移会失败或截断。工程上的做法是采用“扩展—迁移—收缩”三步法：先加新字段并双写，再回填数据，最后在确认无引用后才删除旧字段。

第二，大表锁与执行耗时。在 MySQL 中对千万级大表执行 ALTER TABLE，若使用 ALGORITHM=COPY 会锁表并重建整表，可能持续数十分钟，期间业务写入全部阻塞。应优先使用 ALGORITHM=INPLACE, LOCK=NONE，或借助 gh-ost、pt-online-schema-change 等在线工具。迁移脚本必须设置超时与分批策略，例如按主键区间每批 5000 行回填。

第三，多环境漂移。开发、测试、预发、生产四套库若长期手工维护，结构必然出现差异。CI/CD 要求所有环境的结构都由同一套迁移脚本推导，任何手工改库都应被检测并告警。

第四，数据一致性与中断恢复。迁移执行到一半进程被杀，数据库可能处于“半迁移”状态。因此每个迁移脚本要么在事务中执行，要么设计成可重复执行（幂等），并在 schema_migrations 表中记录版本号与校验和，重启后能判断哪些已执行、哪些需继续。

三、典型场景与工程化价值

数据库迁移 CI/CD 的典型场景包括：微服务拆分时的库表拆分与数据搬迁；单体应用上云时的引擎替换（如 Oracle 迁 PostgreSQL）；多租户 SaaS 的按租户分库分表；以及日常迭代中的加字段、加索引、数据订正。这些场景的共同点是变更频繁、影响面大、需要可追溯。

工程化价值可以概括为三点：可重复——同一套脚本在任意环境执行结果一致；可验证——迁移前后有自动化校验，如行数比对、关键字段非空率、索引命中率；可回滚——每个变更都有对应的回滚脚本或补偿方案，失败时能在分钟级恢复。

四、一个最小可运行的迁移记录表

无论使用 Flyway、Liquibase 还是自研工具，核心都依赖一张版本记录表。下面给出一个可直接参考的建表与查询示例（以 PostgreSQL 为例，属于教学示例，非实测结果）：

CREATE TABLE schema_migrations (
    version      VARCHAR(64)  PRIMARY KEY,
    description  VARCHAR(255) NOT NULL,
    checksum     VARCHAR(64)  NOT NULL,
    installed_by VARCHAR(64)  NOT NULL,
    installed_on TIMESTAMP    NOT NULL DEFAULT now(),
    execution_ms INTEGER      NOT NULL,
    success      BOOLEAN      NOT NULL DEFAULT false
);

-- 查询最近 5 次迁移执行情况
SELECT version, description, success, execution_ms, installed_on
FROM schema_migrations
ORDER BY installed_on DESC
LIMIT 5;

流水线中，迁移阶段应输出上述查询结果作为日志，并设置准出条件：success = true 且 execution_ms 未超过预设阈值（例如 30000 毫秒）。若任一迁移失败，流水线立即中止，禁止应用发布，并触发回滚脚本。这样，数据库变更就从“上线时的手工冒险”变成了“可观测、可门禁、可回滚的工程环节”。

建立端到端交付视角的关键，是把数据库迁移看作与代码同源的制品：它进入版本库、经过 CI 校验、在 CD 中按序执行、有记录、有门禁、有回滚。理解这一点，后续的迁移工具选型、脚本编写规范、流水线编排与生产发布策略，才有统一的落脚点。