别再把 SQL 发群里了：用 Flyway 把数据库变更升级成一套发布工程

>一套系统，代码能做版本管理，配置能进配置中心，镜像能进流水线，为什么数据库变更还经常靠“群里发 SQL、上线前人工执行”？这篇文章把 6 篇 Spring Boot × Flyway 教程重新拉成一条主线，用更高视角来讲清楚：Flyway 解决的不是“SQL 怎么跑”，而是“数据库如何像代码一样发布”。 我是老李。 最近连续整理了 6 篇关于 Spring Boot × Flyway 的文章。单篇看，它们分别讲入门、Migration 管理、Schema 演进、CI/CD、生产安全和企业治理；合在一起看，它们其实构成了一条非常完整的数据库工程升级路线。 所以这篇文章，不是简单摘要，而是要把它们重新组织成一篇适合公众号发布的综合文章：前面讲痛点和方法，中间讲落地架构与实践，结尾给出教程导航，方便你继续深入阅读。 ## 01、痛点 很多团队已经把应用发布做得很工程化了：代码走 Git，构建走 CI，发布走 CD，配置走配置中心，日志和监控也有完整链路。但一到数据库这里，常常又退回到“人肉时代”。 最常见的情况有三种。第一种，开发改完表结构后，把 SQL 发到聊天群里，测试环境执行一次，预发环境执行一次，生产再执行一次；到底哪个环境跑过、哪个没跑过，最后只能靠人回忆。第二种，某条 SQL 在测试阶段临时改过，结果线上版本和仓库里保存的脚本内容不一致，后续再核对时根本说不清。第三种，应用上线节奏越来越快，但数据库变更仍然没有明确的发布纪律，导致系统发布看起来很自动化，实则最危险的环节还是手工操作。 问题的本质不是“不会写 SQL”，而是数据库变更没有被当成一类正式的发布资产来管理。代码有版本，镜像有版本，数据库为什么没有？一旦数据库没有版本化，就很难回答下面三个关键问题： - 当前这个环境，数据库究竟处于哪个状态？ - 这次发布，到底执行了哪些变更？ - 如果线上出问题，问题来自代码、配置，还是数据库历史不一致？ 这正是 Flyway 要补上的那块拼图。 ## 02、是什么 Flyway 本质上做了三件事。 第一，它把数据库变更从“散落在聊天记录里的 SQL”变成一组有版本号的迁移脚本。比如 **V1__init.sql**、**V2__add_order_column.sql** 这样的文件，不只是为了好看，而是在明确告诉系统：数据库演进是有顺序、有历史、有约束的。 第二，它会在执行前后进行对比和校验。Flyway 会扫描 migration 目录，确认哪些脚本已经执行过，哪些还没执行，再按顺序把待执行的脚本迁移到目标数据库中。这个动作让数据库变更第一次像代码部署一样具有“可重复执行”的工程属性。 第三，也是最关键的一点，它通过 **flyway_schema_history** 这张历史表，把数据库状态记录下来。也就是说，数据库不再只是一个“当前长什么样”的静态结果，而变成了一个“它为什么会变成这样”的动态历史。 所以，如果要用一句话概括：**Flyway 不是一个简单的 SQL 执行器，而是一套数据库版本管理机制。** ## 03、为什么 把这 6 篇教程放在一起看，会发现它们实际上不是平铺的知识点，而是一条很完整的升级路径。 第一阶段是接入。先让 Spring Boot 能够集成 Flyway，让数据库结构第一次纳入应用启动和交付过程。这一步解决的是“从无到有”。 第二阶段是版本管理。你开始理解 migration 文件如何命名，为什么执行过的脚本不能随便修改，为什么 checksum 这样一个看似技术细节的能力，背后其实是在帮助团队守住“历史不可篡改”的边界。 第三阶段是 Schema 演进。现实项目里困难的从来不是第一次建表，而是业务上线后不断改表、加字段、补索引、做数据迁移。Flyway 让这些变化变成一套连续的、可审计的过程。 第四阶段是进入 CI/CD。此时数据库变更不再只是本地开发的一项附带工作，而真正成为发布流水线中的一个正式环节：先校验、再评估、再迁移、再上线。 第五阶段是生产安全与排障。比如 checksum 不一致怎么办？已有老库怎么纳入版本体系？执行失败后怎么处理？这些问题决定了 Flyway 能不能从“实验室工具”升级成“生产工具”。 第六阶段是治理。包括规则、审批、权限、审计、多环境策略、团队最佳实践。走到这一步，Flyway 其实已经不只是一个框架，而是数据库发布工程的基础设施。 ## 04、架构 如果从架构视角看，Flyway 最值得重视的不是某一个注解或配置项，而是它把数据库变更纳入了一条统一交付链。 开发在代码仓库中提交业务代码时，同时提交 migration 脚本；系统在 CI 阶段先做校验，比如命名是否规范、版本是否冲突、脚本是否能在临时数据库里正确执行；通过之后，进入发布审批；最终在目标环境中迁移数据库，再启动应用。 这种方式最大的改变是：数据库从“发布前最后一个人工步骤”，变成“流水线中的标准环节”。一旦建立起这条链路，团队的协作方式也会发生变化。开发不再只是“提个 SQL”；测试不再只是“帮忙跑一下脚本”；DBA 也不再只是“发布窗口执行命令的人”。 从系统层面看，这意味着数据库也终于拥有了自己的“发布协议”。 ## 05、实战 如果你准备在团队里落地，我建议不要把这件事想得太重。最好的路径不是一次性全面改造，而是按照下面这个顺序推进。 1. 先从新项目做起。直接在 Spring Boot 中接入 Flyway，跑通第一版 migration，让团队熟悉最基本的目录、命名和执行机制。 2. 建立版本纪律。明确什么是 Versioned Migration，什么是 Repeatable Migration，约定已执行脚本只增不改，避免在历史文件上反复动手。 3. 训练 Schema 演进能力。学会把数据库变化拆成“扩展—迁移—收缩”三个阶段，而不是一条危险的破坏性 SQL 直接上生产。 4. 把校验前移到 CI。让问题尽可能在合并代码时暴露，而不是等到生产发布时才发现 migration 冲突、命名混乱、脚本不可执行。 5. 形成发布闭环。数据库变更进入审批、执行、记录、追踪全链路，最终和应用发布协同起来。 实际落地里，最容易被忽略的一点是：**数据库与应用必须围绕兼容窗口协同发布。** 比如先增加兼容字段，再回填数据，再切换应用逻辑，最后删除旧结构。真正成熟的团队，不会幻想所有数据库变更都能随时完美回滚，而是会优先设计前滚兼容能力。 ## 06、洞见 通过这 6 篇内容，我自己有三个更清晰的判断。 第一，数据库版本化不是锦上添花，而是工程化的底线能力。只要系统还在持续迭代，数据库就不可能停在一个静止状态。既然它一直在变，就必须有版本、有证据、有流程。 第二，Flyway 最大的价值不是自动化，而是确定性。自动执行 SQL 只是表象，真正让团队受益的是：数据库当前状态不再依赖口头沟通，而变成可以被查询、验证、追踪的事实。 第三，工具带来的不是简单提效，而是责任边界的清晰化。以前数据库出问题，大家容易互相甩锅；引入迁移历史和发布规则之后，谁提交、谁审批、谁执行、谁验证，都会越来越清楚。 换句话说，Flyway 的意义不止在“让开发更省事”，更在于“让团队发布更靠谱”。 ## 07、行动 如果你准备开始用 Flyway，有几个高频风险一定要提前避开。 - 不要修改已经在生产执行过的 V 脚本。因为一旦历史内容被改写，checksum 就会漂移，后续所有环境的一致性都会变得可疑。 - 不要把回滚想得过于简单。很多 DDL 和数据迁移天然不可逆，所以比起依赖 Undo，更应该依赖兼容性设计和分阶段发布。 - 不要让多节点应用在启动时无边界地争抢迁移权。规模稍大一点的系统，最好让数据库迁移成为一个明确的发布动作，而不是所有实例都可能去执行的隐式动作。 - 生产环境必须慎用甚至禁用 clean。这个配置如果放错地方，破坏半径往往是整个 Schema。 - Baseline 虽然是纳管老系统的重要手段，但也不能图省事随便用。基线一旦定错，就会把错误状态正式登记进历史体系。 真正安全的姿势只有一句话：**生产只增不改，迁移先验证，破坏性变更分阶段。** ## 08、小结 Flyway 这套内容最值得吸收的，并不是某个孤立技巧，而是一种新的思考方式： - 数据库变更不是附属物，而是发布资产； - 数据库状态不是记忆，而是证据； - 数据库上线不是单点动作，而是完整流程； - 数据库治理不是 DBA 一个人的事，而是研发体系的一部分。 很多团队做了很久 DevOps，却迟迟没有把数据库真正纳入进来。Flyway 恰好提供了一个非常现实的起点：不用推倒重来，只要从 migration 开始，就能逐步把数据库接进版本化、自动化和治理化体系。 ## 09、链接与概念说明 **教程导航（按推荐阅读顺序）** 1. [第1篇：Flyway 入门与 Spring Boot 集成](https://cloud.tencent.com/developer/article/2734549) 2. [第2篇：Migration 版本管理实战](https://cloud.tencent.com/developer/article/2734548) 3. [第3篇：Schema 演进与数据库变更设计](https://cloud.tencent.com/developer/article/2734545) 4. [第4篇：数据库变更进入 CI/CD](https://cloud.tencent.com/developer/article/2734543) 5. [第5篇：生产安全与常见故障处理](https://cloud.tencent.com/developer/article/2734763) 6. [第6篇：企业级数据库治理与最佳实践](https://cloud.tencent.com/developer/article/2734541) **关键概念速记** - **Migration**：数据库迁移脚本，是数据库变化的最小交付单元。 - **Versioned Migration**：带明确版本号的脚本，通常只执行一次。 - **Repeatable Migration**：可重复执行的脚本，适合视图、过程等对象。 - **Checksum**：对脚本内容做一致性校验，防止历史被悄悄篡改。 - **Schema History**：迁移历史表，用来记录数据库执行过哪些变更。 - **Validate / Baseline / Repair**：分别对应校验、老库纳管、历史修复三个场景。