避坑指南：MySQL 迁移到 TiDB

一、为什么选择 TiDB？先搞懂"它值不值得迁"

TiDB 是 PingCAP 出的分布式 NewSQL 数据库，兼容 MySQL 协议，但底层是分布式架构（TiKV + TiFlash）。

简单说，它像 MySQL 的"升级版"------单机用着像 MySQL，集群时能水平扩展到 PB 级。

MySQL vs TiDB

我的建议：如果你的 MySQL 已经分库分表了，或者数据量超 TB 级，TiDB 绝对是救星。

小项目？先试试云 MySQL 吧，别急着迁。

二、迁移前准备：别急着上，评估一下你的"家底"

在开始迁移之前，我们先要做个全面的"体检"：

1. 数据评估

数据量：TiDB 适合 >100GB 的场景，小表迁过去也没问题，但别迁测试库。

查询复杂度：检查慢 SQL（用 EXPLAIN），TiDB 对复杂 JOIN 友好，但分区键设计要优化。

业务依赖：TiDB 兼容 80% MySQL 语法，但不支持存储过程、触发器------这些得重写。

工具推荐：用 pt-query-digest 分析慢查询日志，生成报告。

2. 数据兼容性评估

TiDB宣称高度兼容MySQL协议，但真的是100%兼容吗？

实话告诉你：没有100%的兼容。

兼容性检查清单：

SQL语法差异：

存储过程、触发器、自定义函数不支持

某些JSON函数的用法有差异

自增ID的实现机制不同

3. 业务影响分析

哪些业务强依赖MySQL特有功能？

是否有使用TiDB不支持的特性？

三、手把手迁移步骤：从备份到切流，6 步走完

我们假设你有 500GB 数据，业务是电商订单系统。整个过程控制在 4-8 小时内（灰度切流）。

步骤 0：环境搭建

测试环境：TiUP（TiDB 官方工具）一键部署测试集群。

java 复制代码

curl -s https://tiup-mirrors.pingcap.com/install.sh | sh
tiup playground --tag tidb-v7.5.0

备份 MySQL：用 mysqldump 全量备份 + binlog 增量。

java 复制代码

mysqldump -u root -p --single-transaction --routines --triggers db_name > full.sql

小 tip：先在测试环境跑 1-2 周，模拟生产流量（用 JMeter）。

步骤 1：全量迁移数据

用 TiDB Data Migration (DM) 工具，官方支持 MySQL 到 TiDB 的无损迁移。

下载 DM：tiup install dm-master dm-worker。

配置 dm.yaml（源 MySQL + 目标 TiDB）：

java 复制代码

source-id: 1
from:
  host: 192.168.1.100
  port: 3306
  user: root
  password: "pass"
to:
  host: 192.168.1.200
  port: 4000  # TiDB 端口
  user: root
  password: "pass"

启动：tiup dmctl start task migrate.yaml。

时间：全量 2-4 小时，视网络而定。DM 会自动处理 schema 和数据。

步骤 2：增量同步 Binlog

DM 支持实时 Binlog 同步，确保迁移期间数据不丢。

开启 MySQL Binlog：SET GLOBAL binlog_format = 'ROW';。

DM 配置中加 binlog-position 点位。

监控：DM Dashboard 查看延迟（目标 <1s）。

坑点：Binlog 格式必须 ROW 模式，否则 TiDB 解析不了。

步骤 3：Schema 适配

TiDB 兼容 MySQL，但有些地方要调：

分区表：TiDB 支持 HASH 分区，改成 PARTITION BY HASH(id) PARTITIONS 8。

索引：全局二级索引（GSI）自动，但大表索引重建耗时长------分批建。

字符集：统一 utf8mb4。

用 pt-online-schema-change 工具在线改表，避免锁表。

步骤 4：应用层适配

Java 项目最简单，只改 JDBC URL：

java 复制代码

// 从
jdbc:mysql://mysql-host:3306/db?useSSL=false
// 到
jdbc:mysql://tidb-host:4000/db?useSSL=false&tidb_txn_mode=RC

加 tidb_txn_mode=RC（读已提交隔离，性能更好）。

测试连接池（HikariCP 支持 TiDB）。

测试：跑单元测试 + 压测，确保 QPS 不降反升。

步骤 5：灰度切流

双写双读：先双写（MySQL + TiDB），读 TiDB 验证一致性。

监控工具：用 Prometheus + Grafana 盯延迟、错误率。

回滚预案：Binlog 点位记录，随时切回 MySQL。

时间：灰度 1-2 天，观察无异常再全量切。

步骤 6：迁移后优化

TiFlash 加速 OLAP：加 TiFlash 节点，实现实时分析（SELECT COUNT 秒级出）。

TiCDC：用 CDC 工具同步到下游（如 Kafka），解耦业务。

监控：TiDB Dashboard + SQL 审计，优化慢查询。

四、踩过的坑：避雷指南

迁移的过程中总是会遇到各种各样的坑。分享几个真实案例：

五、结语：迁移不是终点，而是新起点

从 MySQL 到 TiDB 的路，不长，但得一步步来。

它不是"换个数据库"，而是拥抱分布式思维------让你的系统从"扛不住"变成"无敌"。

如果你正纠结迁移，记住：小步快跑，先测试环境试水。

TiDB 的兼容性，让 90% 的项目零痛点迁入。