Flyway:一款免费开源的数据库变更管理工具

凌晨三点，线上订单突降90%，一查日志是某次手工改库把用户表删了半列，老板在群里连发七条语音。

那张表本该在两周前就加字段，结果三个同事各跑了一遍脚本，版本号全乱，生产直接炸。

这种场面，见过一次就忘不掉。

Flyway干的事，就是替人记住每一次改动。

第一次启动，它会偷偷在库里建一张schema_version，往后再有任何脚本，文件名必须按V1__、V2__排好队。

跑过就盖章，没跑就排队，漏跑、重跑、顺序错，统统不存在。

脚本可以是.sql，也可以是.java。

想给PostgreSQL加索引，写V7__add_index.sql；想给MySQL做数据迁移，写V8__migrate.java。

CI/CD里加一句mvnflyway:migrate，上线那分钟就把库同步完，回退也有undo脚本兜底。

GitHub上9.1k星只是表面，Maven中央仓库每月下载量超180万次才是真热度。

SpringBoot把Flyway当成默认迁移组件，连start.spring.io勾选SQL框都会自动带进来。

阿里、、京东的公开技术文章里，关键词Flyway出现频率年年走高。

有人拿Liquibase和它比，后者XML配置多，学习曲线陡。

小团队工期紧，Flyway五分钟就能跑通：建文件夹db/migration，扔脚本，启动应用，完事。

省下的时间拿去写业务代码，比折腾DSL舒服。

企业版多了个基线功能，能把已有数据库拍个快照当V1，后续再按版本走。

老系统想接Flyway，不用再补几百条历史脚本，直接baseline搞定，老板看见成本核算表都松一口气。

真正踩坑的是多人协作。

两个同事同时写V6__，谁先合并谁赢，后合并的会冲突。

团队规矩：改库先开分支，脚本名用时间戳精确到秒，冲突概率直线下降。

再配个GitLab CI强制检查脚本命名，问题基本绝迹。

数据库种类早就不止MySQL。

ClickHouse、TiDB、CockroachDB全在支持清单，连国产达梦也能跑。

一次帮客户迁到OceanBase，只换了驱动和连接串，脚本零改动，省下两周适配时间。

见过最离谱的案例，一家游戏公司把Flyway嵌进客户端，玩家本地SQLite升级也走Flyway，版本号跟服务器保持一致。

安装包缩了30M，热更新再也不怕表结构对不上。

工具再好用，也挡不住乱写脚本。

见过把千万级表加列写成update set col=0，锁表半小时。

规矩是：大表操作一律pt-online-schema-change，脚本里只留alter，工具由Flyway调，风险降到最低。

数据是公司的命，改库是动刀。

动刀前让工具按顺序、留痕迹、能回滚，比任何口头约定都靠谱。

省下的心力，拿去优化索引、分析慢查询，比半夜爬起修库体面得多。