3. 数据库迁移概念与工具选型
数据库迁移（Database Migration）是管理数据库结构（Schema）与数据变更的工程化实践。在微服务与容器化架构下，数据库迁移必须与应用的版本发布同步，确保开发、测试、生产环境的一致性。本章将系统梳理迁移的核心概念，并对主流迁移工具进行横向对比。
3.1 什么是数据库迁移
数据库迁移包含两个核心维度：Schema 变更与数据迁移。两者通常组合出现，但变更对象与风险等级不同。
| 维度 | 定义 | 典型操作 | 风险等级 |
|---|---|---|---|
| Schema 变更 | 修改数据库结构定义 | CREATE TABLE、ALTER TABLE ADD COLUMN、DROP INDEX、CREATE FOREIGN KEY | 高（可能导致应用中断） |
| 数据迁移 | 在结构变更前后移动或转换数据 | 数据回填、字段拆分、类型转换、数据清洗 | 中高（数据一致性风险） |
| 版本回滚 | 撤销已应用的迁移 | 执行降级脚本、恢复备份 | 高（需提前设计回滚方案） |
实践建议：在容器化环境中，数据库迁移应作为应用启动流程的一部分，而非手动执行。推荐将迁移脚本打包到镜像中，通过初始化容器（Init Container）或应用入口脚本自动执行。
3.2 数据库迁移的核心流程
一个完整的数据库迁移生命周期包含以下步骤：
- 编写迁移脚本：使用 SQL 或 DSL 描述变更（如
V1__create_users.sql）。 - 版本记录：工具在数据库中创建元数据表（如
flyway_schema_history），记录已执行的迁移。 - 变更检测：启动时扫描迁移文件目录，对比元数据表，识别未应用的迁移。
- 顺序执行：按版本号或时间戳顺序执行迁移脚本，保证幂等性。
- 校验与回滚：校验迁移结果，必要时执行回滚脚本恢复至上一版本。
3.3 常见迁移工具对比
业界主流的数据库迁移工具各有侧重，选择时需考虑语言生态、数据库支持、回滚能力、容器化适配等因素。
| 工具 | 语言 | 迁移文件格式 | 回滚支持 | 数据库支持 | 容器化友好度 |
|---|---|---|---|---|---|
| Flyway | Java（支持 CLI） | 纯 SQL / Java | 需手动编写回滚脚本 | MySQL、PostgreSQL、Oracle、SQL Server 等 20+ | 高（官方 Docker 镜像，Init Container 模式） |
| Liquibase | Java（支持 CLI） | SQL / XML / YAML / JSON | 内置回滚（自动生成或手动） | MySQL、PostgreSQL、Oracle、SQL Server 等 20+ | 高（官方 Docker 镜像，支持 Spring Boot 集成） |
| Alembic | Python | Python（使用 SQLAlchemy） | 内置回滚（downgrade() 函数） |
SQLAlchemy 支持的所有数据库 | 中（需自行构建镜像，依赖 Python 运行时） |
| golang-migrate | Go | 纯 SQL / Go 函数 | 需手动编写回滚脚本 | MySQL、PostgreSQL、SQLite、MongoDB 等 15+ | 高（静态编译，单二进制，适合 Distroless 镜像） |
3.4 工具选型决策因素
在容器化与微服务架构下，选型应重点考虑以下维度：
- 语言生态匹配：Java 项目优先 Flyway/Liquibase；Python 项目选 Alembic；Go 项目选 golang-migrate。
- 回滚策略：Liquibase 和 Alembic 内置回滚机制，Flyway 和 golang-migrate 需要手动编写降级脚本。
- 迁移文件格式：纯 SQL 文件（Flyway/golang-migrate）更通用，Python 函数（Alembic）更灵活但依赖运行时。
- 容器化适配：golang-migrate 编译为静态二进制，适合
scratch或distroless镜像；Flyway 和 Liquibase 需要 JRE。 - CI/CD 集成：所有工具都支持命令行调用，可嵌入 Jenkins、GitLab CI、GitHub Actions 等流水线。
避坑提醒：不要在生产环境使用
--auto-commit 或自动回滚模式。数据库迁移应始终在事务中执行，并提前在预发布环境验证。对于大表（千万级），ALTER TABLE 可能锁表，建议使用 pt-online-schema-change 或 gh-ost 配合迁移工具。
3.5 容器化迁移架构
在 Docker 环境中，数据库迁移通常作为独立容器运行，与应用容器分离。下图展示了一种推荐的容器化迁移架构：
3.6 迁移文件命名规范
无论使用哪种工具，迁移文件的命名都应遵循统一的版本约定，以保证执行顺序正确：
| 工具 | 命名模式 | 示例 |
|---|---|---|
| Flyway | V<版本号>__<描述>.sql |
V1__create_users.sql、V2__add_email_index.sql |
| Liquibase | <changelog>.xml/yaml/json/sql |
changelog-1.0.xml（内部通过 changeSet id 排序） |
| Alembic | <版本哈希>_<描述>.py |
e3b0c442_create_users.py |
| golang-migrate | <版本号>_<描述>.up.sql / .down.sql |
000001_create_users.up.sql、000001_create_users.down.sql |
最佳实践：在团队协作中，建议使用时间戳作为版本号（如
20250401_120000_create_users.up.sql），避免多人同时开发时版本冲突。同时，每个迁移文件应只包含一个逻辑变更，便于回滚和代码审查。