mydumper加速TB级迁移的关键在于显式启用多表并发（-j）、单表分片（-t + --rows/--chunk-filesize）及规避权限与一致性陷阱；仅加-j不加-t和分片参数，千万行以上大表仍单线程导出。
mydumper 能加速 TB 级迁移，但默认配置下它几乎不会比 mysqldump 快——关键在显式打开多表并发 + 单表分片 + 避开权限和一致性陷阱。
为什么加了 -j 8 还是导出慢？
因为 -j 只控制“同时导多少张表”，对单张千万行以上的表毫无作用。真正决定大表速度的是 -t（单表线程数）和分片参数，而这两者必须同时满足三个条件才生效：
- 表必须有主键或唯一非空索引（否则
-t直接被忽略） - 必须指定
--rows=500000或--chunk-filesize=64（二者互斥，推荐前者） - 不能漏掉
--no-locks或--use-savepoints，否则遇到长事务会卡住或静默失败
例如导出一张 2500 万行的订单表：mydumper -B sales -T orders -o /dump -j 4 -t 4 --rows=500000 --no-locks --use-savepoints。没 -t 和 --rows，哪怕 -j 16，这张表仍单线程扫完才切下一张。
TB 级导出时线程和分片怎么设不翻车？
盲目堆高 --threads 或把 --rows 设太小，会导致磁盘 IO 拥塞、inode 耗尽、导入时 OOM。实际要按硬件匹配：
- SSD/NVMe：从
--threads=8起步，上限一般不超过 12；--rows=200000～500000更稳（--chunk-filesize受字段长度影响大，容易偏差） - 机械盘：别超
--threads=4，--rows=100000起步 - 导出目录 inode 快爆了？立刻
df -i查，超 90% 就rm -f旧 dump 目录——调参不如清空间快
另外加 --skip-tz-utc 可省掉每次连接执行 SET TIME_ZONE 的开销，实测快 5%～10%，对 TB 级很可观。
导出中途失败，怎么补而不是重来？
mydumper 不支持断点续传，但文件命名规则清晰：db.table.00001.sql、db.table.00002.sql……序号即分片编号。补缺三步走：
- 查日志末尾的
Thread X failed，进--outputdir执行ls db.table.*.sql | wc -l，对比预期分片数（如--rows=500000对应 20 片却只生成 18 个，说明缺 .00019 和 .00020） - 只缺某几个分片：用
--where="id > 9500000 AND id 手动补（注意引号转义） - 整张表重跑：加
--regex='^db\.table$' --overwrite-tables，千万别删整个目录再跑——mydumper不校验已有文件，会生成.00001.00001.sql这类冲突名
最容易被忽略的致命细节
权限和一致性配置错误，比慢更致命：
- 缺
LOCK TABLES权限 → 静默跳过表，导出不全却无报错 - 没加
--no-locks --no-binlog就在 GTID 环境下跑 → 可能破坏主从同步 - 源库是 MySQL 8.0+，目标库是 5.7，又没加
--no-binlogs --no-gtids→myloader尝试还原 GTID 直接报ERROR 1840 (HY000) - 目标库连接卡住无响应？先确认
myloader版本 ≥ v0.10.0，旧版不支持caching_sha2_password认证插件
这些不是“优化项”，是导出前必须验证的底线。跑半天发现导出缺表或主从断了，远比多花两小时调参更难收场。
