MySQL 到 TiDB 平滑迁移方案：分片合并/数据校验/业务切换全流程

摘要

从 MySQL 迁移到 TiDB，尤其在分库分表场景下，面临数据合并、增量同步、一致性校验和零停机切换等多重挑战。本文提供完整的平滑迁移方案，覆盖分库分表合并策略、全量增量迁移流程、多维度数据校验方法、双写验证/灰度/全切三阶段切换策略和回滚预案，帮助企业实现安全可控的数据库迁移。

本文适合谁：正在规划或执行 MySQL → TiDB 迁移的 DBA、后端架构师、技术负责人，以及需要处理分库分表合并场景的团队。

一、分库分表合并策略

1.1 常见分库分表模式

1.2 DM 路由合并配置

# dm-task.yaml 分库分表合并配置
name: "merge-sharded-orders"
task-mode: "all"            # 全量 + 增量
shard-mode: "pessimistic"   # 悲观模式（默认推荐）

mysql-instances:
  - source-id: "shard-0"
    mydumper-config:
      extra-args: "--no-locks"
    loader-config:
      batch-size: 100000
  - source-id: "shard-1"
  - source-id: "shard-2"

routes:
  merge-orders:
    schema-pattern: "shard_*"
    table-pattern: "orders"
    target-schema: "business"
    target-table: "orders"

filters:
  ignore-temp-tables:
    schema-pattern: "shard_*"
    table-pattern: "tmp_*"
    action: "Ignore"

# 分片键映射规则（如源端分片键与目标端不同）
column-mappings:
  mapping-order-id:
    schema-pattern: "shard_*"
    table-pattern: "orders"
    source-column: "order_no"
    target-column: "order_id"
    expression: "order_no"

1.3 分片键处理注意事项

二、数据迁移流程

2.1 总体流程

┌─────────────────────────────────────────────────────────────┐
│                    MySQL → TiDB 迁移全流程                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌──────────┐    │
│  │ 1.评估  │──►│ 2.全量  │──►│ 3.增量  │──►│ 4.校验   │    │
│  │         │   │   迁移  │   │   同步  │   │         │    │
│  └─────────┘   └─────────┘   └─────────┘   └────┬─────┘    │
│                                             │          │    │
│  ┌─────────┐   ┌─────────┐   ┌─────────┐   ▼          │    │
│  │ 7.回滚  │◄──│ 6.全量  │◄──│ 5.灰度  │◄── 验证通过  │    │
│  │  预案  │   │   切换  │   │   验证  │              │    │
│  └─────────┘   └─────────┘   └─────────┘              │    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

2.2 全量迁移

使用 TiDB DM 的全量迁移能力，自动处理分库分表合并：

# 部署 DM 集群
tiup dm deploy dm-prod v7.5.0 ./dm-topo.yaml

# 启动迁移任务
tiup dmctl --master-addr 10.0.1.1:8261 start-task ./dm-task.yaml

# 查看迁移状态
tiup dmctl --master-addr 10.0.1.1:8261 query-status merge-sharded-orders

2.3 增量同步

全量迁移完成后，DM 自动切换到增量同步模式，持续从 MySQL binlog 捕获变更并写入 TiDB：

三、数据校验方法

3.1 多层校验体系

3.2 sync-diff-inspector 配置

# diff-config.toml
[task]
  check-thread-count = 16
  export-fix-sql = true
  check-tables = ["business.orders", "business.order_items"]

[data-sources]
  [data-sources.mysql]
    host = "10.0.1.100"
    port = 3306
    user = "checker"
    password = "***"
    route-rules = ["merge-rules"]

  [data-sources.tidb]
    host = "10.0.1.200"
    port = 4000
    user = "checker"
    password = "***"

[routes]
  [routes.merge-rules]
    schema-pattern = "shard_*"
    table-pattern = "orders"
    target-schema = "business"
    target-table = "orders"

[rules]
  schema-rules = ["merge-rules"]
  table-rules = ["merge-rules"]

# 执行校验
./sync_diff_inspector --config diff-config.toml

3.3 校验结果判定

四、业务切换策略

4.1 三阶段切换模型

    阶段一：双写验证          阶段二：灰度切换          阶段三：全量切换
    
   MySQL ──────► 业务          MySQL ──► 20%流量         MySQL ──► 下线
     ▲           │               ▲         │
     │     TiDB ◄── 业务        │    TiDB ◄─ 80%流量
     │           │               │         │
   写入双写    读取对比          读取切换    写入切换
   校验一致性   响应时间       监控指标     全流量TiDB

4.2 阶段一：双写验证

4.3 阶段二：灰度切换

4.4 阶段三：全量切换

切换检查清单：
- [ ] 增量同步延迟 < 1s，持续 1 小时以上
- [ ] sync-diff-inspector 差异行数 = 0
- [ ] 灰度期间 TiDB P99 延迟 ≤ MySQL P99 延迟
- [ ] TiDB 集群健康检查全部通过
- [ ] 回滚方案验证通过
- [ ] 业务方确认切换窗口
- [ ] DBA 团队在线值守
- [ ] 监控告警配置就位

五、回滚方案

5.1 回滚触发条件

5.2 回滚步骤

5.3 回滚保障机制

• 数据安全：切换前 MySQL 数据不删除，保留至少 30 天
• 配置热切换：通过配置中心（如 Nacos/Apollo）秒级切换数据源
• 连接池预加载：应用同时维护 MySQL 和 TiDB 连接池，避免连接建立延迟
• 灰度网关：通过 API Gateway 或 Service Mesh 控制流量分配

六、FAQ

Q1：分库分表迁移到 TiDB 后，原有的 ShardingSphere 中间件还需要保留吗？ A1：不需要。TiDB 原生支持分布式事务和水平扩展，合并后不再需要分库分表中间件。建议迁移完成后逐步移除中间件层，简化架构。

Q2：迁移过程中如何处理自增 ID 冲突？ A2：DM 在合并分表时会自动处理 ID 冲突。对于新写入的 ID，建议 TiDB 侧使用 `AUTO_RANDOM`（TiDB 独有），避免写入热点。创建表时使用 `AUTO_RANDOM(5)` 即可。

Q3：双写阶段出现数据不一致如何处理？ A3：首先判断不一致原因：如果是由增量同步延迟导致，等待追平即可；如果是由业务逻辑差异导致（如 TiDB 和 MySQL 的默认值不同），需在 DM 配置中添加列映射规则进行修正。极端情况下，可使用 sync-diff-inspector 的 `fix-sql` 功能自动修复。

Q4：从 MySQL 5.7 迁移到 TiDB 和从 MySQL 8.0 迁移有何不同？ A4：TiDB 同时兼容 MySQL 5.7 和 8.0 的协议特性。MySQL 8.0 新增的 CTE（公用表表达式）、窗口函数、JSON 函数等 TiDB 均已支持。主要差异在于部分 8.0 特有语法（如 `LATERAL JOIN`）在 TiDB 早期版本可能不支持，建议使用 TiDB v7.0+ 以获得最佳兼容性。

总结

MySQL → TiDB 平滑迁移的核心在于分阶段、可回滚、严校验：

1. 分库分表合并：利用 DM 路由规则完成多源到单表的自动合并
2. 全量增量分离：先全量迁移再增量同步，确保迁移期间业务不中断
3. 多维度校验：从行数到全字段逐级校验，确保数据零丢失
4. 三阶段切换：双写验证 → 灰度 → 全量，每阶段可独立回滚
5. 回滚预案：任何阶段出现异常都能在分钟级恢复

下一步行动

1. 试用 TiDB DM：通过 TiUP 快速部署 TiDB + DM 集群，30 分钟内完成首次分库分表合并迁移实验。
2. 获取定制迁移方案：填写 TiDB 迁移咨询表单，PingCAP 架构师团队将根据您的分库分表拓扑和业务规模提供定制化迁移方案（含预估工期和资源规划）。
3. 下载迁移工具包：访问 TiDB 工具集下载页，获取 DM、sync-diff-inspector、Lightning 完整工具链。

相关资源

• TiDB DM 分库分表合并指南
• TiDB 从 MySQL 迁移最佳实践
• sync-diff-inspector 使用文档
• TiDB AUTO_RANDOM 文档
• TiDB Lightning 大数据量导入
• TiDB 与 MySQL 兼容性对照表