TiDB千万级数据迁移首选tidb-lightning而非DM，因其物理导入比DM逻辑导入快10倍以上；需合理配置dumpling参数（-r、-t、--consistency等）及lightning核心参数（region-concurrency、max-kv-pairs、disk-quota），并提前处理主键/唯一键冲突。
千万级数据（约 10–50 GB）用 tidb-lightning 迁移，通常能在 10–30 分钟内完成，前提是硬件达标、表结构合理、无主键冲突。
为什么不用 DM 直接全量迁移
DM 的全量阶段走的是逻辑导入（类似 mysqldump + 批量 INSERT），单线程吞吐受限，对千万级数据来说往往要数小时甚至更久；而 tidb-lightning 使用物理导入模式（直接生成 SST 文件写入 TiKV），速度可提升 10 倍以上。
常见错误现象：dm-worker 日志持续卡在 "importing data"，CPU 占用低，SHOW PROCESSLIST 里大量 INSERT 等待，说明正在走慢路径。
适用场景：
- 源库允许短时只读（导出期间停写或锁表）
- 目标 TiDB 集群空闲，能承受短时高 IO/CPU 压力
- 不需要在迁移中实时同步增量（否则需搭配 DM 或
binlog补偿）
dumpling 导出时必须加的关键参数
导出质量直接影响 tidb-lightning 后续能否成功导入。默认参数对千万级表容易失败或极慢。
必须设置的参数：
-
-r 100000：按行切分大表，避免单文件过大、OOM 或超时；值太小（如1000）会生成过多小文件，拖慢 lightning 解析 -
-t 8：提高并发导出线程数（根据源库 CPU 核数调整，建议 ≤ 源库可用核数 × 0.7） -
--consistency lock：确保一致性快照（比flush tables with read lock更轻量，适合多数 OLTP 场景） -
--no-views --no-sys-tables：跳过视图和系统表，避免 lightning 不支持的对象报错
不推荐：--csv 输出——lightning 对 CSV 支持弱，易因字段转义、NULL 处理出错；坚持用默认的 SQL 格式（.sql）最稳。
tidb-lightning 配置里最容易被忽略的三项
lightning 默认配置是为小规模测试设计的，千万级数据必须调优，否则会卡住、OOM 或报一堆 "invalid memory address" / "region not found" 错误。
核心配置项（写在 tidb-lightning.toml 中）：
-
region-concurrency = 16：默认是 5，千万级建议设为逻辑 CPU 核数的 75%（如 24 核就设 16），太高会导致 TiKV region 压力爆炸 -
max-kv-pairs = 1000000：默认 30 万，太小会让 lightning 频繁 flush，大幅拖慢；设到 100 万较平衡 -
disk-quota = "100GB"：必须显式设置！lightning 会预估排序空间，不设可能因磁盘不足直接退出；值应 ≥ 最大单表大小 × 2
性能影响提示：如果目标 TiDB 开启了 enable-global-index 或有大量二级索引，lightning 导入时间会显著增加（索引构建是瓶颈），可考虑先禁用非关键索引，导入完成后再建。
主键/唯一键冲突导致导入中断怎么办
这是合库合表或跨实例迁移时最常踩的坑：多个源表导出后合并到同一张目标表，id 或 order_no 等字段重复，lightning 默认行为是直接报错退出，不会跳过或覆盖。
解决路径只有两条：
- 提前清洗：导出前在 MySQL 侧用
UPDATE table1 SET id = id + 1000000000类方式做分段偏移（需业务允许且 ID 未被下游强依赖） - 改用
strict-format = false+ 自定义on-duplicate策略（仅限 TiDB v6.1+）：在配置中启用[mydumper.csv]段并设duplicate-resolution = "replace"，但注意这会把冲突行整行替换，不是 merge 字段
容易被忽略的点：即使你确认没有主键冲突，也要检查 UNIQUE KEY（比如邮箱、手机号字段），lightning 对所有唯一约束一视同仁；用 SELECT COUNT(*) FROM table GROUP BY email HAVING COUNT(*) > 1 快速扫一遍。
