1. Liquibase 概述：数据库迁移的标准化引擎
1.1 什么是 Liquibase
Liquibase 是一个开源的、与数据库无关的数据库变更管理工具。它通过声明式或 SQL 格式定义数据库结构变更（Schema Change），并将这些变更存储在 变更集（ChangeSet） 文件中，由 Liquibase 按顺序执行、跟踪和回滚。其核心思想是：将数据库版本控制提升到与应用程序代码同等的管理级别。
核心工作流： 开发人员编写变更集 → Liquibase 计算当前数据库状态与目标状态之间的差异 → 自动生成并执行迁移脚本 → 将执行记录写入
DATABASECHANGELOG 表。
1.2 数据库迁移的痛点
在传统开发流程中，数据库变更管理长期处于“手工作坊”阶段，以下痛点尤为突出：
| 痛点 | 具体表现 | 典型后果 |
|---|---|---|
| 变更不可追溯 | 开发人员直接登录生产库执行 DDL，无记录、无审批 | 上线后无法确认谁在何时改了什么 |
| 环境差异失控 | 开发、测试、预发、生产四套数据库结构不一致 | 测试通过，上线报错；回滚困难 |
| 多分支冲突 | 多个特性分支同时修改同一张表，合并时产生冲突 | 手动合并脚本容易遗漏或顺序错误 |
| 回滚成本高 | 没有标准回滚脚本，只能靠 DBA 手动逆向操作 | 回滚时间长，数据丢失风险大 |
| 缺乏版本关联 | 数据库版本与应用代码版本无法对应 | 回退应用版本后数据库结构不匹配 |
⚠ 常见误区： 很多团队认为“用 Navicat 导出 SQL 并保存到 Git 就算版本控制”。实际上，这只能记录最终状态，无法保证执行顺序、幂等性和回滚能力，与真正的数据库迁移管理相差甚远。
1.3 Liquibase 的核心优势
Liquibase 通过标准化框架解决了上述痛点，其核心优势可归纳为以下六个维度：
- 数据库无关性： 同一套变更集可自动适配 MySQL、PostgreSQL、Oracle、SQL Server、MariaDB、DB2、H2 等 20+ 数据库，无需为不同数据库编写多套脚本。
- 幂等执行： 每个 ChangeSet 执行后会在
DATABASECHANGELOG表中记录 MD5 校验和，重复执行时自动跳过，确保“运行一次”与“运行多次”结果一致。 - 双向追踪： 既支持从变更集向数据库正向迁移，也支持从数据库反向生成变更集（
generateChangeLog），便于基线化和审计。 - 多格式支持： 变更集可使用 XML、YAML、JSON 或原生 SQL 编写，团队可根据技术栈灵活选择。
- 回滚自动化： 支持自动生成回滚脚本（
rollback），也可手动编写回滚逻辑，实现一键回退到任意历史版本。 - CI/CD 集成： 提供 Maven、Gradle、Spring Boot、命令行、Java API 等多种集成方式，可无缝嵌入 Jenkins、GitLab CI、GitHub Actions 等流水线。
1.4 适用场景
Liquibase 并非万能工具，但在以下场景中能发挥最大价值：
| 场景 | 说明 | 推荐度 |
|---|---|---|
| 微服务架构 | 每个服务独立数据库，需要统一管理多个数据库的版本演进 | ★★★★★ |
| 多环境部署 | 开发 → 测试 → 预发 → 生产，需要确保结构一致性 | ★★★★★ |
| CI/CD 流水线 | 数据库变更作为流水线的一环，自动执行和验证 | ★★★★★ |
| 合规审计 | 金融、医疗等监管行业，需要完整的变更记录和回滚能力 | ★★★★☆ |
| 开源/内部工具 | 需要支持多种数据库的开源项目或内部平台 | ★★★★☆ |
| 小型单体应用 | 数据库结构简单、变更频率低，手动管理即可 | ★★☆☆☆ |
💡 选型建议： 如果你的团队已经使用 Flyway，且对 SQL 原生脚本有强烈偏好，Flyway 也是不错的选择。Liquibase 更适合需要复杂变更编排（如条件执行、回滚逻辑、多格式支持）的团队。本课程后续将对比两者的差异，帮助你做出更明智的选择。