是，mydumper默认单线程导出，必须显式指定-t参数（如-t 4）并配合--rows或--chunk-filesize才能对单张大表分片并行读取，否则仍为全表顺序扫描。
mydumper 能显著加快百万级以上 MySQL 表的导出速度，但默认配置下它不自动启用多线程压缩或并行写入，直接用会卡在单线程瓶颈上。
mydumper 导出慢，是不是没开 -t 参数？
mydumper 默认只用 1 个线程导出所有表，即使加了 -j（jobs）也无效——-j 控制的是「并发导出多少张表」，而 -t 才控制「单张表内部切分多少线程读取」。百万级单表必须显式指定 -t，否则仍为全表顺序扫描。
-
-t 4：对一张大表按主键范围切分成 4 段，并行 SELECT - 必须配合
--chunk-filesize或--rows使用，否则-t不生效 - 若表无主键或唯一索引，
-t会被忽略，退化为单线程
导入时 mysqldump 的 source 命令太慢，换 myloader 为什么还卡住？
myloader 是专为 mydumper 输出设计的并行导入工具，但它默认只开 4 个线程（-t 4），且每线程默认禁用 autocommit。实际导入速度取决于目标库的 I/O 和事务提交频率。
- 务必加
-t 16（根据 CPU 核数和磁盘 IO 调整，8–32 之间较稳） - 必须加
--disable-binlog，否则 binlog 写入会拖慢 3–5 倍 - 导入前在目标库执行
SET FOREIGN_KEY_CHECKS=0和SET UNIQUE_CHECKS=0，否则唯一/外键校验吃 CPU - myloader 不支持跳过已存在表，重复导入会报错，需手动
DROP TABLE或先清空
mydumper 导出文件太多，磁盘 inode 占满怎么办？
mydumper 按表+chunk 切分，一张千万行的表开启 -t 8 可能生成上百个 .sql 文件，小文件密集写入容易打爆 ext4 的 inode 限额（尤其 Docker 容器或某些云盘）。
- 用
--chunk-filesize=256（单位 MB）限制单文件大小，减少文件总数 - 避免
--rows设得太小（如 10000），否则 chunk 过碎；建议从 100000 起调 - 导出后用
tar -cf dump.tar *.sql打包再传输，既省 inode 又压缩体积 - 检查
df -i，inode 使用率超 90% 时，rm -f旧 dump 目录比调优更有效
导出数据一致性怎么保障？--single-transaction 不起作用？
mydumper 的 --single-transaction 仅对 InnoDB 表生效，且要求全局事务隔离级别为 REPEATABLE READ。如果源库开了 read_only=OFF 且有长事务未提交，导出仍可能看到部分新数据或被阻塞。
- 导出前执行
SELECT TRX_ID, TRX_STARTED FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 1，确认无运行超 30 秒的事务 - 对 MyISAM 表，
--single-transaction无效，必须用--lock-all-tables（停写）或接受非一致性快照 - 若源库启用了 GTID，加
--skip-triggers --skip-events --no-schemas避免 GTID 冲突，结构单独导 - 导出完成后立刻校验
mydumper --check（需提前安装 mydumper-check 工具）
真正卡点不在工具选型，而在是否意识到：mydumper 的线程模型是「表级并行 + 表内分片」两级控制，漏掉任意一级参数（-j 或 -t）都会回归单线程；而导入端的 binlog、foreign key、autocommit 三者任一未关，速度就掉一半。
