2、数据库版本管理基础
数据库版本管理是数据库迁移 CI/CD 流水线的基石。没有统一的版本标识，团队无法判断哪个数据库实例处于哪个变更状态，也无法在多个环境间可靠地执行增量或回滚操作。本节从 Schema 版本的概念出发，建立版本号规范，并对比主流工具的设计差异。
2.1 数据库 Schema 版本的概念
数据库 Schema 版本是对数据库结构（表、视图、索引、存储过程、触发器等）在某一时间点的完整快照或增量变更的标识。与应用程序代码的版本管理不同，数据库版本管理具有以下核心特征：
- 状态性：数据库是有状态的，Schema 版本必须与数据共存，不能像代码一样随意切换分支。
- 顺序性：变更必须按时间顺序线性应用，不能跳跃或乱序。
- 幂等性：同一版本脚本在已应用的环境中不应重复执行。
- 可追溯性：每个版本应记录作者、时间、变更描述和校验和。
核心概念：数据库 Schema 版本 ≠ 应用代码版本。应用版本可以并行发布，数据库版本必须串行演进。一个数据库实例在任何时刻只能处于一个确定的 Schema 版本。
2.2 版本号规范：语义化版本
语义化版本（Semantic Versioning，SemVer）为数据库迁移提供了清晰、可比较的版本号格式。标准格式为 MAJOR.MINOR.PATCH，但在数据库场景下，通常扩展为 MAJOR.MINOR.PATCH.BUILD 或使用时间戳/序列号。
| 字段 | 数据库场景含义 | 示例 |
|---|---|---|
| MAJOR | 不兼容的 Schema 变更（如删除表、重命名列、修改主键） | 2.0.0 |
| MINOR | 向后兼容的新增（如新增表、新增可空列、新增索引） | 1.3.0 |
| PATCH | 内部修复或优化（如修改注释、调整默认值、重建索引） | 1.0.1 |
| BUILD / 时间戳 | CI/CD 自动生成的构建序号或 UTC 时间，确保唯一性和顺序 | 1.0.0.20250315 |
实践建议：在数据库迁移中，推荐使用
V{MAJOR}.{MINOR}.{PATCH}__{描述}.sql 的命名格式。例如 V2.1.0__add_user_roles_table.sql。Flyway 和 Liquibase 均原生支持此类前缀解析。
2.3 常见版本管理工具对比
目前业界主流的数据库版本管理工具有 Flyway、Liquibase 和 Alembic。它们在版本跟踪机制、变更描述方式、数据库兼容性和 CI/CD 集成能力上存在显著差异。
| 特性维度 | Flyway | Liquibase | Alembic |
|---|---|---|---|
| 版本跟踪表 | flyway_schema_history |
DATABASECHANGELOG |
alembic_version |
| 变更描述方式 | 纯 SQL 文件（按文件名排序） | XML / YAML / JSON / SQL（changelog） | Python 脚本（迁移函数） |
| 版本排序机制 | 文件名前缀版本号（V1__、V2__） | changelog 内 changeSet 的 id + author |
迁移文件版本号（如 0001_initial.py） |
| 回滚支持 | 有限（需手动编写撤销脚本） | 原生支持（rollback 标签） |
原生支持（downgrade() 函数） |
| 数据库兼容性 | MySQL、PostgreSQL、Oracle、SQL Server 等 20+ | MySQL、PostgreSQL、Oracle、SQL Server 等 30+ | 主要支持 PostgreSQL、MySQL、SQLite |
| CI/CD 集成 | 命令行 + Maven/Gradle 插件 + Docker | 命令行 + Maven/Gradle 插件 + Docker + Spring Boot | 命令行 + Python 脚本 + Docker |
| 学习曲线 | 低（纯 SQL 即可） | 中（需学习 changelog 格式） | 中高（需 Python 和 ORM 基础） |
2.4 版本管理工具架构对比
下图展示了三种工具在数据库版本管理中的核心架构差异，重点体现版本跟踪表与迁移脚本的交互方式。
2.5 工具选型决策要点
在选择数据库版本管理工具时，建议从以下维度进行技术评估：
- 团队技术栈：Java 生态优先考虑 Flyway 或 Liquibase；Python 生态优先考虑 Alembic。
- 回滚需求：如果频繁需要回滚操作，Liquibase 和 Alembic 的原生回滚支持更成熟。
- CI/CD 集成深度：Flyway 的纯 SQL 方式在流水线中最为轻量；Liquibase 在 Spring Boot 项目中集成度最高。
- 数据库多样性：如果团队同时使用多种数据库（如 MySQL + Oracle + PostgreSQL），Liquibase 的兼容性最佳。
- 版本号管理：所有工具都支持语义化版本，但 Flyway 对文件名版本号的解析最为严格和直观。
常见陷阱：不要将数据库版本管理工具与 ORM 的自动建表功能混为一谈。ORM 的
sync 或 auto-create 模式无法提供版本历史、回滚和校验和验证，在生产环境中必须使用专门的版本管理工具。
2.6 版本号在 CI/CD 中的对齐策略
在 CI/CD 流水线中，数据库版本号需要与应用版本号建立映射关系，以确保部署的可追溯性。下图展示了版本对齐的典型流程：
版本对齐的核心原则是：数据库迁移版本号必须包含应用版本信息。推荐使用 V{MAJOR}.{MINOR}.{PATCH}.{CI_BUILD_NUMBER} 的格式，其中 CI 构建号确保唯一性和顺序性，应用版本号提供业务可读性。
版本对齐示例：
应用 Git Tag:
CI 构建号:
数据库迁移文件:
版本跟踪表记录:
应用 Git Tag:
release-v2.1.0CI 构建号:
20250315.1数据库迁移文件:
V2.1.0.20250315.1__add_user_roles.sql版本跟踪表记录:
2.1.0.20250315.1