【TiDBer 唠嗑茶话会 192】一起聊聊 TiDB 迁移实操体验

🌏 互助交流区 🗣 唠嗑茶话会
1

TiDB 迁移是每位 TiDBer 的必经之路，想要让数据 “搬家” 丝滑无扰，选对工具、产品本身的易用性是关键。本期唠嗑茶话会，一起聊聊 TiDB 迁移的实操体验！欢迎大家在评论区分享自己的经验与建议！

本期话题

  1. 你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
  2. 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？
  3. 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？

参与奖励

留言参与讨论，获得 50 积分 & 经验值！

活动时间

2026.1.26 - 2026.2.2

1 个赞
3

oracle数据库迁移到tidb，公司用的dsg迁移工具，用dsg工具主要是工具对oracle数据库数据迁移比较成熟。tidb自带工具对oracle数据库数据处理还是不够成熟。最大的坑就是外键。

4

从mysql迁移到tidb

5

我觉得tidbit迁移 最应该解决的是 迁移后 数据热点问题，我的意思是 这一块应该自动完成而不是需要dba去该配置 修改建表语句（random）， 事先划分region，这样。应该开发自己往里倒数据或者插入数据，数据库自己就把这些做好

6

1、 sqlserver迁移到tidb，用的kettle迁移的。
2、原生的当时不支持
3、最坑的是数据量大，迁移慢

7

用datax同步的数据

8

1、 sqlserver迁移到tidb，用的kettle迁移的。
2、原生的当时不支持
3、最坑的是数据量大，迁移慢

2 个赞
9

1、 sqlserver迁移到tidb，用的kettle迁移的。
2、原生的当时不支持
3、最坑的是数据量大，迁移慢

2 个赞
10

1、 sqlserver迁移到tidb，用的kettle迁移的。
2、原生的当时不支持
3、最坑的是数据量大，迁移慢

2 个赞
11

Datax 很好用啦，没啥坑，挺顺利的

12
  1. 你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
    oracle迁移到tidb. 大表使用dsg迁移.小表自己拼的sql语句.
  2. 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
    最大坑就是数据库字符集不一致, oracle默认一个中文3位长度, tidb1位. 给到下游的数据超长. 后来统一修改了字段长度
13
  • 你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
    数据量少，就用Navicat，量大了的话得用官方工具。
  • 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？
    自主可控
  • 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
    数据类型不一致
14

1、 mysql迁移tidb
2、兼容性很好
3、最大的坑是不分函数不兼容。

15

我是从 MySQL 5.7（主从架构） 迁移到 TiDB 的，主要承载财务核算和资金流水等核心业务。增量同步和实时灾备场景采用 TiCDC，对接 Kafka 后可同时支撑实时对账、审计日志和下游数仓，延迟稳定在秒级；异构数据集成用 DataX + 自研适配器，因其插件生态灵活；针对财务特有的“双写校验”和“余额一致性快照比对”，我们封装了轻量级校验工具，集成到 CI/CD 流水线中。

16 
  1.     你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？

暂时没有迁移TiDB的需求，如果自行研究，目前使用SQLServer Express版本。工具当然使用原生的。如果厂家都没做好，第三方的只能表示怀疑了。
2. 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？
不发表看法。必须用原厂工具。
3. 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
暂时还没操作中。

17
  1. 你是从哪个数据库迁移到 TiDB 的？ 迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
    我们一开始就是用的TiDB
  2. 不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？
    没有迁移过
  3. 实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
    做过信创迁移，就是系统不一样
1 个赞
18

  1. 从mysql迁移到tidb的，使用DM

  2. DM已经很好用了

  3. 坑暂时没有遇到，就是 DM配置还是复杂些，能有个web平台点点点就更完美了

19

1.Oracle,sqluldr+Lightning
2.实时同步，保障源端有业务的情况下可以实时更新至tidb。异常重试，针对目标端重启等故障，可以不中断当前多表迁移的任务，按照某种规则自动清理异常的数据并开启重试，减少人工操作量。
3.数据的一致性校验是难点。源端数据是变化的，如何大批量验证数据条数是否一致？面对大数据量的情况下，如何验证目标端没有乱码？

20

1、我们用的自研工具
2、因为资源紧张
3、数据量太大，稍微慢点