---
tags: [microservice, database, sharding, replication]
create time: 2026-05-17 14:30
---

# 数据库拆分

## 概述

想象一下：你的电商系统刚上线时只有一张 `orders` 表，数据量不大，一条 SQL 就搞定。一年后，日订单量涨到 100 万，同样的查询慢到了 5 秒——数据库成了瓶颈，你不得不开始考虑：**怎么拆？**

微服务的核心设计原则是 **"每个服务拥有独立数据库"**。这意味着每个服务的表结构、数据存储、甚至数据库类型都可以不同。但当单表数据量持续增长时，你就面临另一个维度的拆分需求。

```mermaid
graph LR
    subgraph "理想状态：微服务 = 独立数据库"
        S1["📦 订单服务<br/>MySQL"]
        S2["👤 用户服务<br/>PostgreSQL"]
        S3["📦 库存服务<br/>Redis + MySQL"]
    end

    style S1 fill:#e8f5e9,stroke:#4caf50
    style S2 fill:#e8f5e9,stroke:#4caf50
    style S3 fill:#e8f5e9,stroke:#4caf50
```

> [!failure] 反面教材：共享数据库
>
> 如果两个微服务连接同一个数据库的同一张表，它们就不再是独立的微服务——你得到的是 **分布式单体**。服务可以随意互相查对方的数据，失去了边界和自治性。这在早期开发中很常见（方便联调），但一定要在正式微服务化之前拆掉。

```mermaid
graph LR
    ORDER["📦 订单服务"] --- SHARED[(❌ 共享 DB)]
    USER["👤 用户服务"] --- SHARED

    style SHARED fill:#ffebee,stroke:#ef5350
    style ORDER fill:#fff3e0,stroke:#ff9800
    style USER fill:#fff3e0,stroke:#ff9800
```

## 两种拆分思路：先"纵向切"，再"横向切"

拆分不是选择题，而是**两步走**：第一步按业务域垂直拆分（微服务化的标配），第二步当单个表太大时再水平拆分（分库分表）。

### 第一步：垂直拆分 — 按业务域独立建库

> [!question] 思考一下
>
> 如果一个"用户下单"操作需要同时访问订单表和商品信息表——这说明这两个表应该属于同一个数据库吗？
>
> **答案是否定的。** 商品不会因为你改了订单就跟着变。真正的判断标准是：**哪些表经常一起被修改？** 如果一组表的变更总是由同一个业务逻辑触发，它们就属于同一个限界上下文，应该放在同一个库里。

核心做法：以 **微服务边界** 为基准，将相关表打包到一个数据库中。

```mermaid
flowchart TB
    subgraph DBOrder["DB-Order：订单域"]
        direction LR
        T1[orders]
        T2[order_items]
        T3[order_status_log]
    end

    subgraph DBUser["DB-User：用户域"]
        direction LR
        U1[users]
        U2[user_profiles]
        U3[user_addresses]
    end

    subgraph DBProduct["DB-Product：商品域"]
        direction LR
        P1[products]
        P2[categories]
        P3[product_images]
    end

    style DBOrder fill:#e3f2fd,stroke:#1976d2,rx:8
    style DBUser fill:#e3f2fd,stroke:#1976d2,rx:8
    style DBProduct fill:#e3f2fd,stroke:#1976d2,rx:8
```

| 优势 | 说明 |
|------|------|
| **物理隔离，互不干扰** | 订单库崩了不影响用户登录 |
| **异构选型** | 订单用 MySQL（事务强），搜索用 Elasticsearch，缓存用 Redis |
| **天然解耦** | 服务之间不能直连对方数据库，只能通过 API 通信 |

> [!tip] 拆分的粒度
>
> 不要把一张表里的字段都拆到不同库里——那叫"过度拆分"。**以表为单位**进行垂直拆分是最常见的做法。一个微服务对应一个库，一个库包含多个相关表。

### 垂直拆分的判断标准（实操 checklist）

当你在犹豫某张表应该留在这个库还是挪到另一个库时，用下面几个维度来判断：

```mermaid
flowchart TD
    START["开始判断"] --> A["这张表和当前库里的表<br/>是否经常被同一个事务修改？"]
    A -->|是| SAME_DB["留在同一库 ✅"]
    A -->|否| B["它们是否属于同一个<br/>业务限界上下文？"]
    B -->|是| SAME_CTX["考虑放在同一库<br/>（降低跨库调用成本）"]
    B -->|否| DIFF_CTX["必须独立建库 ✅"]
    SAME_CTX --> C["变更频率差异大吗？"]
    C -->|高频 vs 低频| SPLIT["建议拆分<br/>（避免互相影响）✅"]
    C -->|同频| SAME_DB
    DIFF_CTX --> END["完成"]
    SAME_DB --> END
    SPLIT --> END
```

| 判断维度 | 放同一库的信号 | 拆开的信号 |
|---------|--------------|----------|
| **事务耦合度** | 经常在一个 `BEGIN...COMMIT` 里一起改 | 各自有独立的写入路径 |
| **读取热点** | 总是被一起查询、一起展示 | 访问模式完全不同 |
| **团队归属** | 同一小组维护 | 不同团队负责（Conway 定律） |
| **数据增长率** | 增长速度接近 | 一个涨得快、一个基本不变 |

> [!note] 经验法则
>
> 如果一组表之间的跨库 JOIN 操作占了日常 SQL 的 **80% 以上**，把它们放在一起通常更合理。反过来，如果大部分关联查询都只需要一次 LEFT JOIN，说明拆分时机已经成熟——因为 JOIN 已经在两个数据库之间产生网络开销了。

## 第二步：水平拆分 — 一张表太大了怎么办？

垂直拆分解决的是"谁来负责什么"的问题。但当 **单个服务内的单表** 达到千万级甚至亿级记录时，就需要水平拆分（也叫分片/Sharding）。

> [!note] 为什么要分？
>
> - 单表超过 2000 万行后，索引效率急剧下降
> - 单机 MySQL 的写入 QPS 通常在 5000~20000，超出后成为瓶颈
> - InnoDB 缓冲池装不下全部索引数据，大量磁盘 IO

水平拆分的核心思想：**把一张大表按规则切成多张小表，分散到不同的数据库实例中。**

```mermaid
graph TB
    subgraph "拆分前：一张表扛所有"
        BIG_TABLE[(order 表 1 亿行)]
    end

    subgraph "拆分后：按 user_id 散列"
        subgraph "DB-01"
            T1[(order_0001 2500 万行)]
        end
        subgraph "DB-02"
            T2[(order_0002 2500 万行)]
        end
        subgraph "DB-03"
            T3[(order_0003 2500 万行)]
        end
        subgraph "DB-04"
            T4[(order_0004 2500 万行)]
        end
    end

    ROUTE["user_id % 4"] -->|"uid=1001"| T1
    ROUTE -->|"uid=2002"| T2
    ROUTE -->|"uid=3003"| T3
    ROUTE -->|"uid=4004"| T4

    style BIG_TABLE fill:#ffebee,stroke:#ef5350
    style T1 fill:#e8f5e9,stroke:#4caf50
    style T2 fill:#e8f5e9,stroke:#4caf50
    style T3 fill:#e8f5e9,stroke:#4caf50
    style T4 fill:#e8f5e9,stroke:#4caf50
```

#### 常见分片策略对比

| 策略 | 怎么分 | 适合场景 | 代价 |
|------|--------|---------|------|
| **哈希取模** `hash % N` | `user_id % 4`，余数决定去哪个库 | 均匀分布，写入均衡 | 扩库时需要迁移大部分数据 |
| **范围划分** `BETWEEN x AND y` | userId 1~10000 → DB-A，10001~20000 → DB-B | 范围查询友好 | 热点账号集中在一个分片 |
| **时间分区** `year_month` | 2024_01 → DB-Jan, 2024_02 → DB-Feb | 按生命周期管理（冷数据归档） | 最新月份写入压力大 |
| **地理位置** | 华东用户 → 杭州 DB，华南 → 广州 DB | 降低跨地域延迟 | 跨区域操作复杂 |

> [!important] 扩容陷阱
>
> Hash Mod 最容易踩坑：当你从 4 个分片扩展到 8 个分片时，`% 4` 变成 `% 8`，**几乎所有数据的新归属都变了**，需要大规模数据迁移。这是一个需要提前规划的重大决策。
>
> 如果扩容是高频需求，建议从一开始就用一致性哈希或预留足够多的槽位。

### 分片扩容方案：不停机迁移

生产环境的扩容不能停服停机——你需要一个 **双写 + 历史数据回迁** 的渐进式流程：

```mermaid
flowchart TD
    A["当前状态: N 个分片<br/>hash % N"] --> B["第一步: 新增 M 个分片<br/>总容量变为 N+M"]
    B --> C["第二步: 双写阶段<br/>新写入同时写到旧分片和新分片"]
    C --> D["第三步: 历史数据回迁<br/>按分片逐个搬移存量数据"]
    D --> E{"全部搬完？"}
    E -->|否| D
    E -->|是| F["第四步: 校验数据一致性<br/>checksum 对比"]
    F --> G["第五步: 切读流量<br/>新请求读新分片"]
    G --> H["第六步: 关闭双写<br/>恢复到单写单读"]

    style B fill:#fff3e0,stroke:#ff9800
    style C fill:#fff3e0,stroke:#ff9800
    style D fill:#e3f2fd,stroke:#1976d2
    style F fill:#e8f5e9,stroke:#4caf50
    style G fill:#e8f5e9,stroke:#4caf50
    style H fill:#f3e5f5,stroke:#7b1fa2
```

| 阶段 | 核心操作 | 关键风险 | 规避方法 |
|------|---------|---------|---------|
| **双写** | 新数据同时写入新旧两套分片 | 数据不一致、写入性能下降 | 用消息队列保证异步双写；设置标记位可快速回滚 |
| **回迁** | 按 user_id 范围分批迁移历史数据 | 迁移期间持续写入导致数据漂移 | 迁移后对已迁移范围做一次增量同步 |
| **切读** | 将读取路由切换到新分片 | 漏读、脏数据 | 先灰度 1% 流量验证，逐步放量 |
| **关双写** | 停止向旧分片写入 | 遗漏最后一段增量数据 | 双写关之前做一次全量 checksum 校验 |

> [!warning] 平滑扩容的时间成本
>
> 假设你有 1 亿条订单数据，网络带宽 1Gbps，压缩后约 50GB。**理论传输时间不到 1 分钟**——但实际中还要考虑锁竞争、慢查询、监控告警等因素。建议给每个分片预留 **2~4 小时** 的迁移窗口期，夜间低峰期执行。

## 业界方案：ShardingSphere

> [!tip] 为什么选 ShardingSphere？
>
> Apache ShardingSphere 是国内使用最广泛的分库分表中间件。它提供三种部署模式：
> - **JDBC**：嵌入应用，零运维（最常用）
> - **Proxy**：独立代理服务，语言无关
> - **Sidecar**：Kubernetes 侧车模式

#### 配置示例

以下是 ShardingSphere-JDBC 的核心配置片段（YAML 格式）：

```yaml
sharding-jdbc:
  data-sources:              # 定义数据源
    ds0: { type: com.zaxxer.hikari.HikariDataSource, ... }
    ds1: { type: com.zaxxer.hikari.HikariDataSource, ... }

  sharding:
    tables:
      orders:                # 逻辑表名
        actual-data-nodes: ds$->{0..1}.orders$->{0..1}
        # 上面的表达式展开后是：ds0.orders0, ds0.orders1, ds1.orders0, ds1.orders1
        table-strategy:
          standard:
            sharding-column: user_id       # 分片键
            sharding-algorithm-name: user-id-mod
        key-generate-strategy:
          column: order_id                 # 主键生成
          key-generator-name: snowflake   # Snowflake 雪花算法

    sharding-algorithms:
      user-id-mod:
        type: MOD
        props:
          sharding-count: 2               # 分成 2 个分片
```

关键点：
- **逻辑表名 vs 实际数据节点**：应用层看到的永远是 `orders`，底层路由到 `ds0.orders0` 等是由中间件透明的完成的
- **分片键选择**：一定要选写入频率高且用于查询条件的字段（如 `user_id`），否则每次查询都要扫全部分片

### 分布式 ID 生成：为什么不能用自增主键？

分库后每个库的 `AUTO_INCREMENT` 是独立的——两个库可能都生成了 `id = 100`。你必须用一种方式保证 **全局唯一**。

#### Snowflake 雪花算法

Twitter 开源的雪花算法是目前最主流的分布式 ID 方案：

```mermaid
graph LR
    subgraph "64-bit 长整型 ID"
        S["符号位<br/>1 bit"]
        T["时间戳<br/>41 bits"]
        D["机器 ID<br/>10 bits"]
        SQ["序列号<br/>12 bits"]
    end

    style S fill:#f5f5f5,stroke:#9e9e9e
    style T fill:#e3f2fd,stroke:#1976d2
    style D fill:#e8f5e9,stroke:#4caf50
    style SQ fill:#fff3e0,stroke:#ff9800
```

| 字段 | 长度 | 作用 | 范围 |
|------|------|------|------|
| **符号位** | 1 bit | 恒为 0（保证 ID 为正数） | - |
| **时间戳** | 41 bits | 毫秒级时间戳 | 可支撑约 69 年 |
| **机器 ID** | 10 bits | 区分部署实例 | 1024 个节点 |
| **序列号** | 12 bits | 同一毫秒内的递增序号 | 每毫秒 4096 个 ID |

> [!note] 核心特性
>
> - **单调递增**：基于时间戳保证整体趋势递增，适合 InnoDB 聚簇索引的 append-only 写入模式
> - **高吞吐**：单实例每秒可生成 4096 × 1000 = 数百万个 ID
> - **无中心节点**：不依赖 ZooKeeper 或数据库，挂掉一个机器不影响其他节点
>
> 如果同一毫秒内生成的 ID 超过 4096 个，算法会 **等待下一毫秒** 再重试——这在实际场景中极少发生（通常 QPS < 10 万）。

#### 备选方案对比

| 方案 | 唯一性保证 | 性能 | 复杂度 | 适用场景 |
|------|----------|------|--------|---------|
| **Snowflake** | 时间戳+机器ID+序列号组合 | 极高（本地生成） | 中 | 通用首选 |
| **数据库号段模式** | 每次从 DB 批量拉取一段 ID | 高 | 中高 | 有现成 DB 基础设施 |
| **UUID** | 随机 128 位 | 高 | 极低 | 对有序性无要求的场景 |
| **Redis INCR** | Redis 原子递增 | 高 | 低 | 已有 Redis 集群 |

> [!warning] UUID 的坑
>
> UUID 虽然简单，但在 MySQL InnoDB 中是 **灾难性的**：因为 UUID 无序，插入位置随机分布，导致大量的页分裂和碎片化。如果必须用 UUID，建议存为 `BINARY(16)` 并用 `UUID_TO_BIN(uuid, 1)` 转换，让它在索引中保持局部有序。

## 跨库查询：拆分之后最难解决的问题之一

> [!question] 经典难题
>
> 用户打开"我的订单"页面。订单服务拿到 `user_id` 查出订单列表，但现在要展示用户的头像和昵称——这些信息在用户库里。数据库已经拆开了，怎么做关联查询？

这是拆分后必然遇到的挑战。没有银弹，只有 **权衡后的取舍**。

### 四种方案对比

```mermaid
mindmap
  root((跨库查询方案))
    冗余字段
      最简单最直接
      少量字段
      快照语义
      一致性问题
    接口组装
      按需查询
      链路长时性能差
      N+1 查询陷阱
      适合低频关联
    CQRS / 宽表
      异步最终一致
      写入有额外开销
      适合高频关联
    搜索引擎
      ES 做多维聚合
      架构重
      适合复杂搜索
```

| 方案 | 一句话描述 | 性能 | 复杂度 |
|------|-----------|------|--------|
| **冗余字段** | 在订单表里直接存用户名字段 | ⭐⭐⭐⭐⭐ | 低 |
| **接口组装** | 先查订单，循环调用户服务补全信息 | ⭐⭐⭐ | 中 |
| **CQRS / 宽表** | 异步同步一份含用户信息的宽表 | ⭐⭐⭐⭐ | 高 |
| **搜索引擎** | 把数据推到 ES，用 ES 做关联查询 | ⭐⭐⭐⭐ | 中高 |

### 实战一：冗余字段（最推荐的首选方案）

```sql
-- 订单表中冗余关键字段（快照模式）
CREATE TABLE orders (
    id         BIGINT PRIMARY KEY,
    user_id    BIGINT NOT NULL,
    username   VARCHAR(64),     -- 下单时的用户名快照
    phone      VARCHAR(20),     -- 下单时的手机号（已脱敏）
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_user (user_id)
);
```

> [!note] 关键理解：快照语义
>
> 用户后来改了名字、换了手机号，**不改订单表**。订单上的 `username` 反映的是下单那一刻的状态，而不是"当前"状态。这不仅是合理的，而且是正确的——用户查看历史订单时，看到的是当时的信息。
>
> 如果需要主动更新冗余字段（如用户更换了头像），通过消息队列通知订单服务批量更新。

Go 代码实现示例：

```go
// 下单时将用户信息快照写入订单表
func (s *orderSvc) CreateOrder(ctx context.Context, req *CreateOrderReq) (*Order, error) {
    // 1. 查用户基本信息
    user, err := s.userClient.GetByID(ctx, req.UserID)
    if err != nil {
        return nil, err
    }

    // 2. 构造订单，携带快照字段
    order := &Order{
        UserID:   req.UserID,
        Username: user.Username, // ✅ 快照：锁定下单时的值
        Phone:    maskPhone(user.Phone),
        Items:    req.Items,
    }
    return s.orderRepo.Save(ctx, order)
}
```

### 实战二：接口组装（轻量场景够用）

适用于关联查询不频繁的场景，比如后台管理系统的偶尔查看详情。

```go
// 查订单 + 补齐用户信息
func (s *orderSvc) GetOrderWithUser(ctx context.Context, orderID int64) (*OrderDetail, error) {
    // 1. 先查订单
    order, err := s.orderRepoFindByID(ctx, orderID)
    if err != nil {
        return nil, err
    }

    // 2. 再调用户服务补齐
    user, err := s.userClient.GetByID(ctx, order.UserID)
    if err != nil {
        return nil, err
    }

    return &OrderDetail{
        Order:    order,
        UserName: user.Username,
        UserHead: user.AvatarURL,
    }, nil
}
```

> [!warning] N+1 陷阱
>
> 如果是列表查询（一次性返回 20 条订单），逐条调用户服务会导致 20 次 RPC 调用。正确做法是：先收集所有 `user_id`，**批量查询**用户信息，再拼回去。

```go
// ❌ 错误：N 次 RPC
for _, o := range orders {
    u, _ := userClient.GetByID(ctx, o.UserID)
}

// ✅ 正确：1 次批量 RPC
ids := collectIDs(orders)                          // [1, 3, 7, 12, ...]
users, _ := userClient.GetByIds(ctx, ids)          // 一次拿回所有
byID := indexBy(users, func(u *User) int64 { return u.ID })
for _, o := range orders {
    o.UserInfo = byID[o.UserID]
}
```

### 实战三：CQRS / 宽表（重度关联查询必备）

当跨库关联是高频操作（如运营后台的多维度筛选），冗余字段就不够了——你需要一套完整的 **事件驱动宽表同步机制**：

```mermaid
sequenceDiagram
    participant U as 用户服务
    participant MQ as 消息队列
    participant O as 订单服务
    participant W as 宽表 (Read DB)

    U->>MQ: UserUpdated 事件 (userId, newAvatar)
    MQ->>O: 消费事件
    O->>W: 更新宽表中对应用户的头像

    Note over W: 宽表包含了订单 + 用户 + 商品的冗余字段<br/>只读，专为查询优化
```

Go 代码实现——事件消费者（订单服务侧）：

```go
// Order宽表同步消费者：监听来自各服务的业务事件，维护一张可跨维度查询的宽表
type WideTableSyncer struct {
    wideDB *sql.DB  // 独立的读库连接
}

// OnUserUpdated 消费用户变更事件，更新宽表中对应用户的信息
func (s *WideTableSyncer) OnUserUpdated(ctx context.Context, evt UserUpdatedEvent) error {
    tx, err := s.wideDB.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    defer tx.Rollback()

    // 批量更新宽表中的用户快照字段
    _, err = tx.ExecContext(ctx,
        `UPDATE order_wide_table 
         SET username = ?, phone_masked = ?, avatar_url = ?
         WHERE user_id = ?`,
        evt.Username, evt.PhoneMasked, evt.AvatarURL, evt.UserID,
    )
    return tx.Commit()
}

// OnOrderCreated 订单创建时写入宽表（包含完整的关联信息）
func (s *WideTableSyncer) OnOrderCreated(ctx context.Context, evt OrderCreatedEvent) error {
    _, err := s.wideDB.ExecContext(ctx,
        `INSERT INTO order_wide_table
         (order_id, user_id, username, product_name, amount, status, created_at)
         VALUES (?, ?, ?, ?, ?, ?, ?)`,
        evt.OrderID, evt.UserID, evt.Username,
        evt.ProductName, evt.Amount, evt.Status, evt.CreatedAt,
    )
    return err
}
```

> [!tip] 宽表设计的三个原则
>
> 1. **反范式化**：宽表故意违反第一范式——同一个用户的名字可能出现在几百条订单记录中。这正是它的价值所在。
> 2. **最终一致性延迟可控**：通过 MQ 保证，通常在 1~3 秒内同步完成。前端加一个 loading 状态即可掩盖这短暂的延迟。
> 3. **写多读少时才考虑**：如果宽表的写入放大超过原始数据的 3 倍，说明你的场景用冗余字段就够了，不需要上宽表。

## 何时该拆？——不要过早拆分

拆分是有 **代价** 的：复杂度上升、运维成本增加、跨服务调用变慢。在决定拆之前，先看这些硬指标是否已经触达：

```mermaid
flowchart TD
    START["你的数据量到了什么级别？"]
    
    START --> SMALL["< 100 万行<br/>单库单机足够"]
    START --> MEDIUM["100 万 ~ 2000 万行<br/>考虑读写分离"]
    START --> LARGE["> 2000 万行<br/>考虑分片"]
    
    SMALL --> S1["✅ 先优化索引"]
    S1 --> S2["✅ 加缓存层 Redis"]
    S2 --> S3["✅ 读写分离<br/>一主多从"]
    
    MEDIUM --> M1["✅ 先做垂直拆分"]
    M1 --> M2["按业务域独立建库"]
    
    LARGE --> L1["✅ 再做水平拆分"]
    L1 --> L2["分库分表 + 宽表同步"]
    
    style SMALL fill:#e8f5e9,stroke:#4caf50
    style MEDIUM fill:#fff3e0,stroke:#ff9800
    style LARGE fill:#ffebee,stroke:#ef5350
    style S3 fill:#e8f5e9,stroke:#4caf50
    style M2 fill:#e8f5e9,stroke:#4caf50
    style L2 fill:#ffebee,stroke:#ef5350
```

> [!quote] 一条经验法则
>
> **"在数据量还没到 2000 万行之前，不要做任何形式的数据水平拆分。"**
>
> 绝大多数系统通过索引优化 + 缓存 + 读写分离就能撑到日活百万级。见过太多团队在项目刚上线就搞分库分表——六个月后回头看，完全是提前踩雷。

### 拆与不拆的判断矩阵

| 场景 | 推荐方案 | 预期寿命 |
|------|---------|---------|
| DAU < 1 万，QPS < 500 | 单库单机，专心做好索引 | 半年~1年 |
| DAU 1~50 万，QPS 500~5000 | 加 Redis 缓存 + 读写分离 | 1~2 年 |
| DAU 50~200 万，单表 > 2000 万行 | 垂直拆分（按微服务） | 2~3 年 |
| DAU > 200 万，单表 > 5000 万行 | 水平拆分 + 宽表同步 | 长期 |

## 数据库迁移工具：告别手动执行 SQL

随着服务拆分增多，SQL 脚本的管理变得复杂。手工执行、口头传达"我跑过 V3 了"的方式不再可行——你需要**版本化的、可重复执行的数据库迁移工具**。

```mermaid
flowchart LR
    Dev["💻 开发环境<br/>git commit SQL 文件"] -->|"CI/CD 自动执行"| Stage["🧪 Staging<br/>flyway migrate"]
    Stage -->|"人工审批"| Prod["🚀 Production<br/>flyway migrate"]
    Prod -->|"校验"| Check["🔒 flyway validate<br/>确认无漂移"]

    style Dev fill:#e3f2fd,stroke:#1976d2
    style Stage fill:#fff3e0,stroke:#ff9800
    style Prod fill:#e8f5e9,stroke:#4caf50
    style Check fill:#f3e5f5,stroke:#7b1fa2
```

### 主流工具对比

| 工具 | 生态 | 特点 |
|------|------|------|
| **Flyway** | Java / Go (via CLI) | 基于文件名命名，纯 SQL 脚本，简单直接 |
| **Liquibase** | Java | 支持 XML/YAML/JSON，自带回滚生成能力 |
| **golang-migrate** | Go | 轻量 CLI，Go 项目首选 |

### Flyway 工作流

```
db/migration/
├── V1__create_users_table.sql
├── V2__add_user_phone.sql
├── V3__create_orders_table.sql
└── V4__add_order_status_enum.sql
```

执行顺序严格遵循版本号：V1 → V2 → V3 → V4。Flyway 会在数据库中维护一张 `_schema_version` 表，记录每个迁移的版本和执行状态。

核心要点：
- **文件名即版本**：`V` 开头 + 序号 + `__` + 描述
- **不可修改已执行的文件**：改了的话 Flyway 会报验证失败（`validate` 阶段）
- **永远不要写"反向"SQL**：迁移脚本只做"升级"，回滚通过发版解决

## 关联笔记

- [[03-数据一致性/02-分布式事务]] — 拆分后的数据一致性问题
- [[01-基础概念]] — DDD 限界上下文与数据库拆分的对应关系