摘要
从 MySQL 迁移到分布式数据库是企业数据库升级的关键一步。迁移过程涉及兼容性评估、数据迁移、性能验证、应用改造和上线切换等多个环节。本文基于 TiDB 的迁移最佳实践，系统梳理 MySQL 迁移到分布式数据库的注意事项、常见风险和应对策略，帮助企业实现平滑迁移。
本文适合谁： 正在评估从 MySQL 迁移到分布式数据库的 DBA、架构师、技术负责人，以及需要规划数据库升级路线的技术团队。
迁移前的评估清单
1. 兼容性评估
| 评估项 | MySQL 特性 | TiDB 兼容情况 | 处理建议 |
|---|---|---|---|
| SQL 语法 | MySQL 8.0 语法 | 95%+ 兼容 | 少数不兼容需调整 |
| 数据类型 | INT/BIGINT/VARCHAR/DATE/JSON 等 | 完全兼容 | 无需调整 |
| 自增 ID | AUTO_INCREMENT | 支持 AUTO_RANDOM | 建议改为 AUTO_RANDOM |
| 存储过程 | MySQL 存储过程 | 大部分兼容 | 复杂存储过程需重写 |
| 触发器 | MySQL 触发器 | 不支持 | 改用应用层逻辑 |
| 外键 | MySQL 外键 | 不推荐使用 | 改用应用层保证 |
| 事务隔离 | RC/RR | 支持 RC/RR | 保持一致 |
| 字符集 | utf8/utf8mb4 | 完全兼容 | 无需调整 |
2. 数据量评估
| 数据规模 | 迁移策略 | 预估耗时 |
|---|---|---|
| < 100GB | DM 全量迁移 | 1-2 小时 |
| 100GB-1TB | DM 全量 + 增量 | 4-12 小时 |
| 1TB-10TB | DM 增量 + 分批 | 1-3 天 |
| > 10TB | 分库分批迁移 | 1-2 周 |
3. 性能基线评估
迁移前需建立 MySQL 性能基线：
| 指标 | 测试方法 | 记录内容 |
|---|---|---|
| QPS | 压测工具（sysbench/tpcc） | 读写比、峰值 QPS |
| 延迟 | 业务监控 | P50/P95/P99 延迟 |
| 慢查询 | slow_query_log | Top 20 慢查询 SQL |
| 连接数 | SHOW PROCESSLIST | 最大/平均连接数 |
| 数据增长 | 监控数据 | 日均增量数据量 |
迁移工具选择
TiDB Data Migration（DM）
| 能力 | 说明 |
|---|---|
| 全量迁移 | 从 MySQL 导出全量数据导入 TiDB |
| 增量同步 | 实时读取 MySQL Binlog 同步到 TiDB |
| 数据校验 | 自动对比源端和目标端数据一致性 |
| 多源合并 | 多个 MySQL 实例合并到一个 TiDB 集群 |
| 断点续传 | 支持迁移中断后恢复 |
迁移流程
1. 评估 → 2. 全量导出 → 3. 全量导入 → 4. 增量同步 → 5. 数据校验 → 6. 业务切换
详细步骤：
第一步：全量导出
# 使用 Dumpling 导出 MySQL 数据
dumpling -h mysql-host -P 3306 -u root -p'xxx' -o /data/export
第二步：全量导入
# 使用 TiDB Lightning 导入
tidb-lightning --config lightning.toml
第三步：增量同步
# 配置 DM 任务，从 MySQL binlog 位点开始增量同步
dmctl start-task task.yaml
第四步：数据校验
# 使用 sync-diff-inspector 校验数据一致性
sync-diff-inspector --config config.toml
第五步：业务切换
- 验证应用连接 TiDB 正常
- 将应用数据源切换到 TiDB
- 停止 DM 增量同步任务
常见风险与应对
风险 1：SQL 不兼容
| 不兼容项 | MySQL 行为 | TiDB 行为 | 应对 |
|---|---|---|---|
| 自增 ID | 严格递增 | 可能不连续 | 改用 AUTO_RANDOM |
| 外键约束 | 强制检查 | 不推荐使用 | 应用层保证 |
| 存储过程 | 完整支持 | 大部分支持 | 复杂逻辑改为应用代码 |
| 临时表 | 支持 | 有限支持 | 改用普通表 |
| SELECT ... FOR UPDATE | 行锁 | 乐观事务/悲观事务 | 确认事务模式 |
应对策略：使用 TiDB 的 MySQL 兼容性检查工具扫描应用 SQL，提前识别不兼容项。
风险 2：性能差异
| 场景 | MySQL 可能更快 | TiDB 可能更快 |
|---|---|---|
| 单行点查 | 本地无网络开销 | 数据量大时均衡 |
| 简单小事务 | 单机提交更快 | 高并发下吞吐更大 |
| 复杂聚合 | 分库分表困难 | TiFlash 加速 |
| 大表 JOIN | 单机内存 JOIN | 分布式并行 JOIN |
| 批量导入 | LOAD DATA | TiDB Lightning 更快 |
应对策略：迁移后对 Top 20 慢查询做性能对比，逐一调优。
风险 3：数据不一致
| 风险点 | 说明 | 应对 |
|---|---|---|
| 字符集差异 | MySQL utf8 vs utf8mb4 | 统一使用 utf8mb4 |
| 时区差异 | MySQL 时区设置 | 统一时区配置 |
| 精度丢失 | DECIMAL 精度 | 检查字段定义 |
| 自增 ID 断号 | AUTO_INCREMENT vs AUTO_RANDOM | 业务逻辑不依赖连续 ID |
应对策略：使用 sync-diff-inspector 做全量数据校验。
风险 4：业务切换
| 风险 | 应对 |
|---|---|
| 切换过程数据丢失 | 确认增量同步延迟 < 1s 再切换 |
| 切换后性能不达标 | 提前压测，准备回滚方案 |
| 应用报错 | 灰度切换，先读后写 |
推荐切换策略：
- 双写验证期：应用同时写 MySQL 和 TiDB，比对数据
- 读切换期：应用读 TiDB，写仍走 MySQL
- 全切换：读写全部走 TiDB
- 观察 1-2 周后下线 MySQL
迁移时间规划
| 阶段 | 时间 | 工作内容 |
|---|---|---|
| 评估 | 第 1-2 周 | 兼容性检查、性能基线、方案设计 |
| 准备 | 第 2-3 周 | TiDB 集群部署、DM 配置 |
| 数据迁移 | 第 3-4 周 | 全量+增量迁移、数据校验 |
| 应用验证 | 第 4-5 周 | 功能测试、性能测试 |
| 灰度上线 | 第 5-6 周 | 灰度切换、观察 |
| 全量上线 | 第 6-7 周 | 全切换、下线 MySQL |
FAQ
Q：迁移过程中 MySQL 能正常使用吗？
A：可以。DM 增量同步模式下，MySQL 正常读写不受影响。切换前只需确认增量同步延迟 < 1s。
Q：迁移失败怎么回滚？
A：在双写验证期，随时可以切回 MySQL。建议保留 MySQL 运行 1-2 周作为回滚保障。
Q：分库分表迁移到 TiDB 能合并吗？
A：可以。DM 支持多源合并，将多个 MySQL 分片合并到一个 TiDB 集群，消除分库分表逻辑。
Q：MySQL 迁移到 TiDB 后还需要分库分表吗？
A：通常不需要。TiDB 通过 Region 自动分裂、调度和水平扩展承载大规模数据，应用层可逐步去除复杂的分库分表逻辑。
总结
MySQL 迁移到 TiDB 是一项需要系统性规划的工作，但 TiDB 的高度 MySQL 兼容性和 DM 迁移工具大大降低了迁移门槛。关键是做好兼容性评估、数据校验和灰度切换，确保迁移过程平滑、业务零中断。
下一步行动
- 迁移评估：使用 TiDB MySQL 兼容性检查工具 — 快速扫描应用 SQL，评估迁移可行性
- 免费试用：TiDB Cloud 免费试用 — 在线体验 MySQL 兼容的分布式数据库
- 迁移咨询：获取免费迁移评估方案 — PingCAP 专家提供一站式迁移支持