数据库迁移工具操作清单：Flyway、Liquibase、Alembic 的差异在“失败之后”

Flyway、Liquibase 和 Alembic 都能把版本化的 schema 变更按顺序应用到数据库，都能记录哪些版本已经执行过，都能在 CI/CD 里作为一个独立步骤运行。它们的差异不在“能不能迁移”，而在迁移失败之后会发生什么，以及团队需要为回滚和并发做多少额外工作。

Flyway 的模型最简单：编号的 SQL 文件加上一张 schema 历史表。它支持普通 SQL 和 Java，生态覆盖 JVM、CLI 和 Docker。回滚在免费版里是有限的，通常需要手写 down 脚本。这个简单性在 PostgreSQL 上是优势，因为 PostgreSQL 支持事务性 DDL，一个迁移要么整体成功，要么整体回滚，失败不会留下半完成的状态。但在 MySQL 上，事务性 DDL 的支持有限，一个多语句迁移中途失败可能留下部分已执行的变更，Flyway 的“按语句自动检测是否需要非事务执行”并不能替你处理这种半完成状态。

Liquibase 的模型更重，但也更完整。它用 XML、YAML、JSON 或 SQL 写 changeset，支持数据库无关的 changelog、自动回滚标签、前置条件和上下文。它适合大型企业、多环境、需要审计和复杂变更管理的场景，代价是学习曲线更高。它的回滚能力比 Flyway 免费版更强，但前提是 changeset 写的时候就考虑了回滚，而不是事后补。

Alembic 是 Python/SQLAlchemy 生态的选择。它从模型差异自动生成迁移脚本，支持分支和合并，回滚通过 downgrade() 实现。它的优势是和 ORM 模型紧密集成，自动生成的迁移省去了手写 DDL 的工作量；代价是自动生成的脚本需要人工审查，尤其是在涉及数据迁移、索引并发创建或列类型变更时，自动生成的版本不一定是最优或最安全的。

不管选哪个，几条操作底线是共同的。第一，迁移必须作为一个独立的流水线步骤运行，并加锁防止并发执行。Kubernetes 里两个 Pod 同时启动、同时跑迁移，是经典的竞态条件；用 Job 或 pre-upgrade hook 加数据库级的 advisory lock 可以避免。第二，超时和失败处理要显式设计，不能让一个卡住的迁移无限期占住部署流程。第三，大表变更要走在线 schema 变更工具，MySQL 生态里的 gh-ost 和 pt-online-schema-change 是为千万级以上表设计的，迁移工具的版本化能力和在线变更工具解决的是不同层面的问题。第四，回滚路径要在 staging 验证过，而不是假设“down 脚本应该能跑”。

选型的核心判断不是“哪个工具功能多”，而是“我的数据库引擎支持什么样的失败语义，我的团队愿意为回滚写多少代码”。PostgreSQL 加 Flyway 的组合在简单性上很难被击败；需要跨数据库 changelog 和审计的企业环境，Liquibase 的额外复杂度是在买回滚和前置条件；Python 团队用 Alembic 的自然成本最低，但自动生成的脚本不能省掉人工审查这一步。