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

TiDBer_mittens · 2026 年1 月 27 日 01:32

1.TiDB 迁移优先选原生工具（Lightning/DM/TiCDC），异构场景用 DataX/Flink 更适配；
2.原生工具核心痛点是适配性、易用性不足，需强化兼容与可视化能力；
3.迁移最大坑是大表迁移效率、数据一致性及业务中断风险。

wfxxh · 2026 年1 月 27 日 02:26

你是从哪个数据库迁移到 TiDB 的？迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
从mysql ndbcluster 迁到tidb，用的DM
实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
无

TiDBer_lEE0p32k · 2026 年1 月 27 日 02:41

1、 mysql迁移tidb，使用的DM
2、兼容性很好
3、无

Augenstern · 2026 年1 月 27 日 03:17

1、 mysql迁移tidb，TiDB 原生工具 DM或Lightning
2、

若源库是 MySQL 系，优先选原生工具（DM+Lightning+TiCDC 组合），适配性和稳定性最优，无需额外适配成本。
若源库是 Oracle/PostgreSQL 等异构数据库，优先选 Flink CDC 或 DataX，前者适合实时同步，后者适合全量迁移。
3、DM/Lightning 仅对 MySQL 生态友好，对于 Oracle、SQL Server 等非 MySQL 源库，原生工具无法直接支持，只能切换第三方工具。

TiDBer_jYQINSnf · 2026 年1 月 27 日 06:23

你是从哪个数据库迁移到 TiDB 的？迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
从mysql 分库分表迁移到 TiDB的，用过 DM，也用过自研的，自研的好处是配置简单，DM 的配置略复杂。
实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
DM 的文档不足够详细，我期望能快速生成一个模板例子，我改改库的账号密码就能用，然后可选的参数以及默认值都列出来，想改什么就改什么。

forever · 2026 年1 月 27 日 07:51

存量数据用Datax迁移的

TiDBer_milan · 2026 年1 月 27 日 08:37

向各位老师学习

呢莫不爱吃鱼 · 2026 年1 月 27 日 09:19

mysql迁移的，用的datax和cloudcanal。cloudcanal实时同步，保证数据一致性。

Sakura6680 · 2026 年1 月 27 日 11:59

对 Lightning 做了少量定制，增强TIMESTAMP 类型到 TiDB 的映射逻辑，增量阶段依赖 TiCDC 捕获 TiDB 的变更日志，输出到 Kafka，实时数仓链路中，用 Flink CDC 直接消费MySQL binlog，经清洗后写入 TiDB 或 TiFlash，支撑实时 BI

evanyou26 · 2026 年1 月 28 日 00:04

你是从哪个数据库迁移到 TiDB 的？迁移 TiDB 都用啥工具？偏爱 TiDB 原生的 DM、Lightning、TiCDC，还是习惯用 DataX、Flink 这些第三方，或者自己自研工具？
mysql迁移过来的，直接用的navicat的工具迁移。
不用 TiDB 原生迁移工具的小伙伴，是因为技术栈适配难、性能不够，还是觉得易用性一般？大家最希望 TiDB 迁移工具加啥实用功能？
navicat能够满足迁移需求，原生的数据量较大或者其他数据场景更实用。
实操 TiDB 数据迁移时，你踩过最坑的是什么？是数据量大迁移慢、一致性难保证，还是业务中断风险，或者工具运维太复杂？
主要是字符集的兼容性问题

洪七表哥 · 2026 年1 月 28 日 00:24

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

望海崖2084 · 2026 年1 月 28 日 00:42

mysq 迁移到 tidb

kelvin · 2026 年1 月 28 日 00:55

Datax 就挺好用的

guitarsoft · 2026 年1 月 28 日 00:57

zhaokede · 2026 年1 月 28 日 01:15

从teledb到tidb，使用的是kettle工具，慢慢迁移的

sonomx · 2026 年1 月 28 日 01:28

白里登风 · 2026 年1 月 28 日 02:24

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

wzf0072 · 2026 年1 月 28 日 05:13

从Mysql 到 TiDB，用的是Cloudcanal

BraveChen · 2026 年1 月 28 日 07:36

mysql 到tidb 订阅

DM 好用

TiDBer_wHJmjTiw · 2026 年1 月 28 日 08:47

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