4. 数据库迁移概念：什么是数据库迁移、迁移与同步的区别、迁移的版本控制思想、GORM AutoMigrate 简介

4.1 什么是数据库迁移

数据库迁移（Database Migration）是指对数据库 Schema（表结构、索引、约束、视图等）进行有计划、可追溯、可回滚的变更管理过程。在应用开发中，随着业务迭代，数据模型会不断演进——新增字段、修改类型、添加索引、拆分表等。迁移的核心目标是将这些变更以代码化、版本化的方式安全地应用到目标数据库，并确保团队协作时不会出现“我的本地能跑，线上却报错”的混乱局面。

核心特征： 迁移 ≠ 直接手动执行 ALTER TABLE。迁移是可重复、可审计、可回滚的自动化流程。

4.2 迁移与同步的区别

很多开发者容易混淆“迁移”和“同步”。下表从多个维度清晰区分两者：

对比维度 数据库迁移（Migration） 数据库同步（Sync）
变更对象 Schema 结构（表、字段、索引、约束） 数据内容（行记录、缓存、副本）
变更方向 单向：从代码模型 → 数据库 双向/单向：主从、主主、CDC 数据流
版本控制 强版本化，每个变更文件有唯一 ID 通常无版本，基于时间戳或偏移量
回滚能力 支持回滚（Down 脚本） 回滚复杂，通常需要全量重建
典型场景 新增字段、修改类型、添加索引 主从复制、数据仓库同步、灾备
工具示例 GORM AutoMigrate、golang-migrate、Flyway MySQL Binlog Sync、Debezium、Canal
一句话总结： 迁移管“结构”，同步管“数据”。迁移是开发阶段的 Schema 演进工具，同步是运维阶段的数据一致性保障。

4.3 迁移的版本控制思想

数据库迁移借鉴了软件版本控制（如 Git）的核心思想：每次变更都是一个不可变的“版本快照”。每个迁移文件通常包含两个部分：

  • Up（升级）：应用本次变更的 SQL 或逻辑（如 ALTER TABLE ADD COLUMN）。
  • Down（回滚）：撤销本次变更的 SQL 或逻辑（如 ALTER TABLE DROP COLUMN）。

版本控制带来的关键优势：

  1. 可追溯：每个迁移文件都有时间戳或序号，可以精确知道数据库在任意时刻处于哪个版本。
  2. 可回滚：当新版本出现 Bug 时，可以快速执行 Down 脚本回到上一个稳定版本。
  3. 团队协作：所有开发者共享同一套迁移文件，避免“我的表结构和你不一样”的冲突。
  4. 环境一致性：开发、测试、预发布、生产环境通过执行相同的迁移序列，保证 Schema 完全一致。
常见误区： 不要在生产环境直接执行 AutoMigrate 的默认行为！AutoMigrate 只做“追加式”变更（新增字段/表），不会删除字段或修改类型。对于破坏性变更（如重命名、删除字段），必须使用手写迁移脚本。

4.4 GORM AutoMigrate 简介

GORM 提供了 AutoMigrate 方法，用于自动将 Go 结构体与数据库表结构保持同步。它本质上是一种轻量级的、无版本控制的迁移工具，适合快速原型开发和简单项目。

// 示例：使用 AutoMigrate 自动创建/更新表
type User struct {
    ID        uint   `gorm:"primaryKey"`
    Name      string `gorm:"size:100"`
    Email     string `gorm:"uniqueIndex"`
    Age       int
    CreatedAt time.Time
}

// 自动迁移：如果表不存在则创建，如果缺少字段则追加
db.AutoMigrate(&User{})

AutoMigrate 的行为规则：

操作类型 AutoMigrate 是否支持 说明
创建新表 ✅ 支持 根据结构体自动生成 CREATE TABLE
新增字段 ✅ 支持 追加 ALTER TABLE ADD COLUMN
修改字段类型 ❌ 不支持 不会自动 ALTER MODIFY，需手动迁移
删除字段 ❌ 不支持 不会自动 DROP COLUMN，避免数据丢失
添加索引 ✅ 支持 根据 tag 自动创建索引
删除索引 ❌ 不支持 不会自动删除旧索引
外键约束 ✅ 支持（需配置） 通过 gorm:"constraint" 标签
最佳实践： 在开发阶段使用 AutoMigrate 快速迭代；在正式项目中，将 AutoMigrate 仅用于“初始化表结构”，后续所有变更通过手写迁移脚本（如 golang-migrate）管理版本。

4.5 迁移流程全景图

下图展示了从代码模型到数据库的完整迁移流程，以及 AutoMigrate 在其中的定位：

数据库迁移流程与 AutoMigrate 定位 数据库迁移流程全景图 Go 结构体定义 AutoMigrate 手写迁移脚本 版本控制表 目标数据库 说明： AutoMigrate 适合快速原型，手写迁移脚本适合生产环境。版本控制表记录每次迁移的 ID、时间、状态。

4.6 版本控制表结构示例

GORM 内部使用一张 schema_migrations 表（或其他命名）来记录迁移历史。一个典型的版本控制表结构如下：

-- 迁移版本控制表示例（MySQL）
CREATE TABLE schema_migrations (
    version     BIGINT       NOT NULL PRIMARY KEY,
    description VARCHAR(255) NOT NULL DEFAULT '',
    applied_at  DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
    checksum    VARCHAR(64)  NOT NULL DEFAULT '',
    dirty       TINYINT(1)   NOT NULL DEFAULT 0
);

-- 查询当前迁移状态
SELECT version, description, applied_at, dirty
FROM schema_migrations
ORDER BY version DESC
LIMIT 5;
关键字段说明：
  • version：迁移版本号，通常使用时间戳（如 20250401000001）或递增序号。
  • dirty：标记迁移是否执行失败（部分执行），用于故障恢复。
  • checksum：迁移文件的哈希值，防止文件被篡改。

4.7 本章小结

  • 数据库迁移是 Schema 的版本化变更管理，区别于数据同步。
  • 版本控制思想让每次变更可追溯、可回滚、可协作。
  • GORM AutoMigrate 提供便捷的自动同步能力，但仅支持追加式变更，不适合生产环境的破坏性操作。
  • 生产项目推荐使用手写迁移脚本 + 版本控制表的组合方案。
← 上一章 📖 返回目录 下一章 →