Flyway迁移脚本参数配置与冒烟检查工程实践 - 第1节

1.1 Flyway 是什么

Flyway 是一款开源的数据库版本控制工具，采用 “约定优于配置” 的设计哲学，通过版本化 SQL 脚本或 Java 迁移类，将数据库 Schema 的变更纳入 Git 等版本管理体系中。它支持命令行、Java API、Maven/Gradle 插件以及 Spring Boot 自动配置等多种集成方式，是目前 Java 生态中最流行的数据库迁移框架之一。

Flyway 的工作原理非常直观：在目标数据库中维护一张元数据表（默认名为 flyway_schema_history），记录每次已执行的迁移脚本的版本号、描述、校验和与执行时间。当应用启动或手动触发迁移时，Flyway 扫描指定路径下的迁移脚本，将尚未执行的脚本按版本号顺序依次执行，并更新元数据表。

-- 示例：Flyway 元数据表结构（简化）
CREATE TABLE flyway_schema_history (
    installed_rank INT NOT NULL,
    version VARCHAR(50),
    description VARCHAR(200),
    type VARCHAR(20),
    script VARCHAR(1000),
    checksum INT,
    installed_by VARCHAR(100),
    installed_on TIMESTAMP,
    execution_time INT,
    success BOOLEAN,
    PRIMARY KEY (installed_rank)
);

1.2 为什么需要数据库版本控制

在传统开发模式中，数据库 Schema 变更往往通过手动执行 SQL 脚本、口头沟通或临时 DDL 操作完成。这种“人肉运维”方式在单体应用时代尚可勉强维持，但在微服务、持续交付、多环境并行的现代研发体系中，暴露出大量问题：

• 环境不一致：开发、测试、预发、生产环境的数据库结构经常出现差异，导致“在我本地是好的”成为常态。
• 变更不可追溯：谁在什么时间改了哪张表、加了哪个索引，缺乏历史记录，回滚时无从下手。
• 协作冲突：多名开发人员同时修改数据库结构，合并时极易产生冲突，且难以自动检测。
• 部署风险高：生产环境执行 DDL 时，依赖人工逐条执行，一旦遗漏或顺序错误，可能导致长时间故障。
• 缺乏自动化：数据库变更无法像应用代码一样纳入 CI/CD 流水线，成为持续交付的最后一公里瓶颈。

数据库版本控制正是为了解决上述痛点而生。它将数据库 Schema 的每一次变更视为一个“版本”，通过脚本化、版本化、自动化的方式，确保所有环境的数据库结构保持一致、可追溯、可回放。Flyway 正是这一理念的最佳实践工具之一。

1.3 Flyway 与传统数据库变更管理的对比

下表从多个关键维度对比 Flyway 与传统手动/半自动变更管理方式的差异：