# MySQL 平替就选 TiDB | 从调研、测试、迁移、上线全流程实施方案

一、项目背景与目标

1.1 MySQL 面临的痛点

随着业务快速增长，传统 MySQL 架构逐渐暴露出以下问题：

1.2 TiDB 的核心优势

TiDB 作为原生分布式数据库，从根本上解决了 MySQL 单机架构的局限：

1.3 迁移目标

1. 平滑迁移：业务代码改动最小化，停机窗口可控
2. 数据安全：全量 + 增量同步，数据零丢失
3. 性能提升：充分利用分布式架构能力，读写性能不低于现网水平
4. 可回退：完整的回退链路，异常时分钟级回退至 MySQL

二、第一阶段：调研选型

2.1 业务需求评估矩阵

2.2 TiDB 与 MySQL 功能兼容性评估

TiDB 与 MySQL 5.7 / 8.0 协议高度兼容，绝大多数场景无需修改应用代码：

兼容性详细参考：TiDB 与 MySQL 兼容性对比

2.3 选型决策 Checklist

[ ] TiDB 核心能力是否匹配业务需求（数据量、并发、SQL 复杂度）
[ ] 不兼容特性是否可接受（外键、存储过程、触发器等）
[ ] 团队学习成本评估（分布式概念、运维工具链）
[ ] 硬件资源评估（TiDB Server / PD / TiKV / TiFlash 节点规划）
[ ] 总拥有成本（TCO）估算（硬件、运维、学习成本 vs MySQL 分库分表方案）
[ ] 社区活跃度和商业支持能力评估
[ ] 同行业落地案例参考

三、第二阶段：测试验证

3.1 测试环境搭建

最小测试集群规划

部署方式选择

# TiUP 快速部署示例
tiup cluster deploy test-cluster v7.5.0 ./topology.yaml -u root -p
tiup cluster start test-cluster
tiup cluster display test-cluster

3.2 功能测试

3.2.1 基础功能测试用例

3.2.2 数据迁移功能测试

# 测试场景 1：单库全量+增量同步
# 使用 DM 工具模拟生产数据同步流程

# 测试场景 2：分库分表合并迁移
# 验证路由规则配置和合并结果正确性

# 测试场景 3：大表迁移（> 1 亿行）
# 验证全量导出导入效率及增量同步稳定性

3.3 兼容性测试：sql-replay

sql-replay 是 TiDB 生态中降低测试成本的核心工具，可一键完成兼容性和性能验证。

3.3.1 工作原理

 MySQL 生产环境
      ↓  抓取 SQL（慢日志 / 抓包 / general_log）
   SQL 文件
      ↓
 sql-replay 回放引擎
      ↓
   TiDB 测试集群
      ↓
 自动生成报告（兼容性 + 性能对比）

3.3.2 操作步骤

# 1. 从 MySQL 生产环境获取 SQL 语句
# 方式一：开启慢日志
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 0;  # 全量抓取

# 方式二：使用 general_log（谨慎使用，影响性能）
SET GLOBAL general_log = ON;

# 2. 使用 sql-replay 回放 SQL
git clone https://github.com/Bowen-Tang/sql-replay.git
cd sql-replay
# 配置 TiDB 连接信息，执行回放
./sql-replay --host tidb-host --port 4000 --user root --sql-file mysql_slow.log

# 3. 查看报告
# 报告包含：
#   - 兼容性问题：不支持的语法、函数、特性
#   - 性能对比：每条 SQL 在 MySQL vs TiDB 的执行时间
#   - 性能退化：是否存在执行时间显著增加的 SQL

3.3.3 测试通过标准

3.4 性能压测

3.4.1 压测工具

3.4.2 sysbench 压测示例

# 准备数据（10 张表，每表 100 万行）
sysbench oltp_read_write \
  --mysql-host=tidb-host --mysql-port=4000 \
  --mysql-user=root --mysql-db=test \
  --tables=10 --table-size=1000000 \
  prepare

# 执行压测（16 线程，运行 300 秒）
sysbench oltp_read_write \
  --mysql-host=tidb-host --mysql-port=4000 \
  --mysql-user=root --mysql-db=test \
  --tables=10 --table-size=1000000 \
  --threads=16 --time=300 \
  --report-interval=10 \
  run

3.4.3 性能对比报告模板

四、第三阶段：数据迁移

4.1 迁移架构总览

┌─────────────┐      DM 全量+增量        ┌─────────────┐
│             │ ──────────────────────→  │             │
│   MySQL     │                           │    TiDB     │
│  (生产集群)  │ ←──────────────────────  │  (目标集群)  │
│             │     TiCDC 回退链路        │             │
└─────────────┘                           └─────────────┘
                                                  │
                                          sync-diff-inspector
                                          数据校验（持续）

4.2 核心迁移工具：TiDB Data Migration (DM)

4.2.1 DM 架构说明

DM-master ─── 集群管理、任务调度
    │
DM-worker ─── 执行具体同步任务
    │
    ├── Dumper（全量）：伪装成 MySQL 从库，DUMP 导出 → 导入 TiDB
    └── Syncer（增量）：实时解析 Binlog → 回放至 TiDB

4.2.2 单库迁移配置示例

# task.yaml - DM 同步任务配置
name: "mysql-to-tidb-task"
task-mode: "all"                          # all = 全量 + 增量

target-database:
  host: "127.0.0.1"
  port: 4000
  user: "root"
  password: "your_password"

mysql-instances:
  - source-id: "mysql-prod-01"
    block-allow-list: "instance"
    mydumper-config-name: "global"
    loader-config-name: "global"
    syncer-config-name: "global"

block-allow-list:
  instance:
    do-dbs: ["your_database"]              # 指定待迁移的库

mydumpers:
  global:
    threads: 8                             # 导出并行度
    chunk-filesize: 64                     # 单个数据块大小（MB）
    extra-args: "--no-locks"               # 避免锁表

loaders:
  global:
    pool-size: 16                          # 导入并行度

syncers:
  global:
    worker-count: 16                       # 增量同步并行度
    batch: 100                             # 批量提交行数

4.2.3 分库分表迁移配置示例

# 分库分表合并为单表场景
routes:
  order-route:
    schema-pattern: "order_db_*"            # 匹配分库
    table-pattern: "t_order_*"             # 匹配分表
    target-schema: "order"                  # 目标库
    target-table: "t_order"                # 目标表（合并为单表）

mysql-instances:
  - source-id: "mysql-shard-01"
    route-rules: ["order-route"]
  - source-id: "mysql-shard-02"
    route-rules: ["order-route"]

4.2.4 DM 任务运维命令

# 创建同步任务
tiup dmctl --master-addr=127.0.0.1:8261 start-task task.yaml

# 查看任务状态
tiup dmctl --master-addr=127.0.0.1:8261 query-status mysql-to-tidb-task

# 暂停任务
tiup dmctl --master-addr=127.0.0.1:8261 pause-task mysql-to-tidb-task

# 恢复任务
tiup dmctl --master-addr=127.0.0.1:8261 resume-task mysql-to-tidb-task

# 停止任务（清理元数据）
tiup dmctl --master-addr=127.0.0.1:8261 stop-task mysql-to-tidb-task

# 查看同步延迟
tiup dmctl --master-addr=127.0.0.1:8261 query-status mysql-to-tidb-task | grep syncerBinlog

4.3 数据校验：sync-diff-inspector

4.3.1 工具特点

• 基于数据块 CRC32 校验值比对，比对效率高达 350MB+/s
• 先比对数据块 CRC32 值，不一致时再下钻到具体行
• 支持多种比对模式：仅表结构、表结构+全量数据、部分列、时间范围

4.3.2 配置与执行

# sync-diff.toml
check-thread-count = 4
export-fix-sql = true                        # 导出修复 SQL

[data-sources]
[data-sources.mysql]
    host = "mysql-host"
    port = 3306
    user = "root"
    password = "your_password"

[data-sources.tidb]
    host = "tidb-host"
    port = 4000
    user = "root"
    password = "your_password"

[task]
    output-dir = "./output"
    source-instances = ["mysql"]
    target-instance = "tidb"

    # 比对模式 1：全库全量比对
    [task.target-check-tables]
        [task.target-check-tables.your_database]
            all = true

    # 比对模式 2：指定表 + 时间范围
    # [task.target-check-tables]
    #     [task.target-check-tables.your_database]
    #         tables = ["t_order", "t_user"]
    #         range = "create_time > '2024-01-01'"

# 执行数据校验
sync_diff_inspector --config=./sync-diff.toml

4.4 迁移策略与时间线

4.4.1 分阶段迁移策略

阶段 1：全量迁移（T0）
  ├── DM Dumper 导出 MySQL 全量数据
  ├── DM Loader 导入至 TiDB
  └── 预计耗时：数据量 / 导入速率（通常 500GB 约 2-4 小时）

阶段 2：增量同步（T1 持续）
  ├── DM Syncer 实时解析 Binlog
  ├── 同步延迟：通常秒级
  └── 持续时间：建议至少 1-2 周

阶段 3：数据校验（T1 持续）
  ├── sync-diff-inspector 持续比对
  └── 目标：数据一致性 100%

阶段 4：性能测试（T1 并行）
  ├── sql-replay 验证兼容性
  ├── sysbench 压测验证性能
  └── 目标：兼容率 > 99%，性能退化 < 5%

阶段 5：回退链路就绪（切换前）
  ├── 关闭 DM 同步链路
  ├── 开启 TiCDC TiDB → MySQL 回退链路
  └── 确认回退链路正常工作

阶段 6：正式切换（T2）
  ├── 选择业务低峰期执行
  ├── 停止 MySQL 写入
  ├── 确认增量数据同步完毕
  └── 切换应用连接至 TiDB

4.4.2 关键时间节点

五、第四阶段：上线切换

5.1 切换前确认清单（Checklist）

[ ] 数据一致性：sync-diff-inspector 校验通过，数据差异为 0
[ ] 兼容性：sql-replay 报告验证通过，兼容率 > 99%
[ ] 性能：压测结果达标，不低于 MySQL 基准水平
[ ] 回退链路：TiCDC 已配置并验证，增量数据可回写至 MySQL
[ ] 监控告警：Grafana Dashboard 配置完成，告警规则生效
[ ] 备份恢复：TiDB 全量备份完成，恢复流程已验证
[ ] 切换方案：切换脚本、回退脚本已评审通过
[ ] 通知机制：相关团队已通知切换时间窗口
[ ] 业务验证：核心业务流程在 TiDB 环境验证通过

5.2 切换操作流程

Step 1：停止业务写入

-- 在 MySQL 生产库设置只读模式
SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;
-- 确认没有活跃写入
SHOW PROCESSLIST;

Step 2：确认增量同步追平

# 查看 DM 同步状态，确认 binlog position 已追平
tiup dmctl --master-addr=127.0.0.1:8261 query-status mysql-to-tidb-task
# syncerBinlog 的 secondsBehindMaster 应为 0

Step 3：最终数据校验

# 执行最终轮数据校验
sync_diff_inspector --config=./final-check.toml
# 预期：数据差异 0 行

Step 4：开启回退链路

# 1. 暂停 DM 同步链路
tiup dmctl --master-addr=127.0.0.1:8261 pause-task mysql-to-tidb-task

# 2. 启动 TiCDC 回退链路（TiDB → MySQL）
# changefeed 配置
tiup cdc cli changefeed create \
  --sink-uri="mysql://root:password@mysql-host:3306/" \
  --changefeed-id="tidb-to-mysql-rollback"

Step 5：切换应用连接

# 应用数据库配置变更（以 Spring Boot 为例）
spring:
  datasource:
    # 原 MySQL 配置
    # url: jdbc:mysql://mysql-host:3306/dbname
    # 新 TiDB 配置
    url: jdbc:mysql://tidb-host:4000/dbname
    username: user
    password: password

Step 6：恢复业务并验证

# 1. 验证 TiDB 读写正常
# 2. 监控 TiDB Dashboard 观察 QPS、延迟
# 3. 验证核心业务流程：登录、下单、支付等
# 4. 观察 Grafana 监控面板，确认无异常

5.3 回退方案

触发条件

• 严重性能退化（P99 延迟增加 > 50%）
• 核心业务功能异常（下单、支付失败）
• 数据不一致（sync-diff 校验失败）
• TiDB 集群严重故障

回退流程

# Step 1：TiCDC 将增量数据实时同步回 MySQL（已预配）
# Step 2：停止业务写入 TiDB
# Step 3：确认 TiCDC 追平
tiup cdc cli changefeed query --changefeed-id tidb-to-mysql-rollback

# Step 4：切换应用连接回 MySQL
# Step 5：关闭 MySQL 只读模式
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

# Step 6：验证 MySQL 业务恢复
# Step 7：恢复 DM 同步链路（为再次迁移准备）

回退耗时：通常可控制在 5-10 分钟以内。

六、运维与管理体系搭建

6.1 监控体系

TiDB 原生集成 Prometheus + Grafana 监控平台，提供丰富的监控指标：

关键告警规则建议

# 示例告警规则
- alert: TiDBHighLatency
  expr: histogram_quantile(0.99, rate(tidb_server_handle_query_duration_seconds_bucket[5m])) > 1
  for: 5m
  annotations:
    summary: "TiDB P99 查询延迟超过 1 秒"

- alert: TiKVStoreDown
  expr: sum(tikv_store_up) < 3
  for: 1m
  annotations:
    summary: "TiKV 节点宕机数量超过容忍阈值"

6.2 备份与恢复

备份策略

# 全量备份
tiup br backup full --pd "pd-host:2379" --storage "s3://backup-bucket/tidb/full/" --ratelimit 128

# 日志备份（开启 PITR）
tiup br log start --pd "pd-host:2379" --storage "s3://backup-bucket/tidb/log/"

# 恢复到指定时间点（PITR）
tiup br restore point --pd "pd-host:2379" --storage "s3://backup-bucket/tidb/log/" \
  --full-backup-storage "s3://backup-bucket/tidb/full/" \
  --restored-ts "2025-06-01 14:00:00"

# 逻辑备份（Dumpling）
tiup dumpling -h tidb-host -P 4000 -u root -p password \
  -B dbname -o /backup/dumpling/

6.3 日常运维对比

6.4 闪回功能使用

TiDB 内核级闪回功能极大简化了数据误操作恢复：

-- 1. 闪回查询（查看某时间点的数据状态）
SELECT * FROM t_order AS OF TIMESTAMP '2025-06-01 14:00:00' WHERE id = 12345;

-- 2. 将误操作前数据恢复到临时表
CREATE TABLE t_order_recovery AS
SELECT * FROM t_order AS OF TIMESTAMP '2025-06-01 13:55:00'
WHERE id IN (SELECT id FROM t_order WHERE status = 'ERROR_STATUS');

-- 3. 从临时表恢复错误数据
UPDATE t_order t
JOIN t_order_recovery r ON t.id = r.id
SET t.status = r.status, t.amount = r.amount
WHERE t.status = 'ERROR_STATUS';

七、开发适配指南

7.1 代码改动量评估

TiDB 与 MySQL 协议高度兼容，绝大多数场景代码改动极小：

7.2 TiDB 特有的最佳实践

7.2.1 事务大小控制

// ❌ 不推荐：大事务
@Transactional
public void batchProcess(List<Record> records) {
    for (Record r : records) {  // records 可能数十万条
        processRecord(r);
    }
}

// ✅ 推荐：分批提交
public void batchProcess(List<Record> records) {
    int batchSize = 100;
    for (int i = 0; i < records.size(); i += batchSize) {
        List<Record> batch = records.subList(i, Math.min(i + batchSize, records.size()));
        transactionTemplate.execute(status -> {
            for (Record r : batch) {
                processRecord(r);
            }
            return null;
        });
    }
}

TiDB 默认事务大小限制：单事务不超过 100MB（可配置 txn-total-size-limit）

7.2.2 避免热点写入

-- ❌ 不推荐：使用自增主键（可能导致写入热点）
CREATE TABLE t_order (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    ...
);

-- ✅ 推荐：使用 AUTO_RANDOM 或 SHARD_ROW_ID_BITS
CREATE TABLE t_order (
    id BIGINT PRIMARY KEY AUTO_RANDOM,
    ...
);

-- 或者使用 SHARD_ROW_ID_BITS 分散写入
CREATE TABLE t_order (
    id BIGINT NOT NULL AUTO_INCREMENT,
    ...
) SHARD_ROW_ID_BITS = 4;

7.2.3 索引使用建议

-- 1. 利用覆盖索引减少回表
CREATE INDEX idx_user_status_time ON t_order(user_id, status, create_time);

-- 2. 分析慢查询
EXPLAIN ANALYZE SELECT * FROM t_order WHERE user_id = 12345;

-- 3. 使用 TiFlash 加速分析查询
ALTER TABLE t_order SET TIFLASH REPLICA 1;
SELECT /*+ READ_FROM_STORAGE(TIFLASH[t_order]) */ ... FROM t_order ...;

7.3 JDBC 连接配置优化

spring:
  datasource:
    url: jdbc:mysql://tidb-host:4000/dbname?useServerPrepStmts=true&cachePrepStmts=true&useConfigs=maxPerformance
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 30000
      idle-timeout: 600000
      max-lifetime: 1800000  # 小于 wait_timeout

八、风险评估与应急预案

8.1 风险矩阵

8.2 应急预案

九、关键工具速查表

十、总结与展望

10.1 迁移核心原则

1. "合适"永远是最重要的 — 基于企业 IT 架构、业务需求、运维能力和未来趋势多维度评估，不盲目跟风
2. 测试验证要前置 — 充分利用 sql-replay 低成本发现兼容性和性能问题，避免上线后"踩坑"
3. 回退方案不可省 — TiCDC 回退链路是迁移安全的最后防线，必须配置并验证
4. 好的数据库是"用"出来的 — 选择开源开放、社区活跃的数据库产品，生态的力量远大于单一产品

10.2 迁移 ROI 分析

10.3 迁移后优化建议

1. 索引优化：启用 SQL 审计（TiDB Dashboard），识别并优化慢查询
2. 开启 TiFlash：分析/报表类查询迁移至列存引擎，体验 MPP 加速
3. 分批下线 MySQL：确认 TiDB 稳定运行 1-2 个月后，逐步释放 MySQL 资源
4. 持续迭代：关注 TiDB 新版本发布，利用新特性持续提升性能和稳定性
5. 知识沉淀：将迁移中积累的经验编写为内部文档，培养团队运维能力

适用 TiDB 版本：v7.x 及以上

本文方案综合参考了 TiDB 官方文档、TiDB vs MySQL Meetup 技术分享及实际迁移案例。具体实施时请结合自身业务特点灵活调整。