mydumper默认单线程导出，必须显式指定-t并配合--rows或--chunk-filesize才能对单张大表分片并行读取，否则仍为全表顺序扫描；无主键或唯一索引时-t被忽略。
mydumper 默认不是多线程加速的，不加关键参数就跑，和 mysqldump 速度基本没区别——它只用 1 个线程导出所有表，哪怕你加了 -j 8，也只是并发导 8 张小表，对单张千万行大表毫无帮助。
为什么加了 -t 还是慢？必须配 --rows 或 --chunk-filesize
mydumper 的 -t 参数只在满足条件时才触发分片并行：表有主键或唯一索引 + 显式指定切分粒度。否则它退化为全表顺序扫描。
-
-t 4单独使用无效；必须搭配--rows=500000（按行数切）或--chunk-filesize=64（按 MB 切） - 无主键/唯一索引的表，
-t被静默忽略，只能单线程扫 - 切得太碎（如
--rows=10000）会导致文件爆炸，df -i容易打满 inode，尤其 Docker 或云盘环境 - 推荐起手值：
--chunk-filesize=32+-t 8，再根据磁盘 IO 和 CPU 核数微调
myloader 导入卡住？默认线程和 autocommit 是隐形瓶颈
myloader 默认只开 4 个线程，且每个线程默认关闭 autocommit，每条 INSERT 都走完整事务流程，I/O 和 binlog 写入直接拖垮速度。
- 导入前务必执行：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0; - 导入命令必须带：
--disable-binlog（否则 binlog 写入慢 3–5 倍） - 线程数别信默认值，按目标库配置设：
-t 16（8–32 之间较稳），超过 CPU 核数 1.5 倍反而争抢严重 - 重复导入会报错，
myloader不跳过已存在表，要用--drop-if-exists或手动清空
跨版本迁移失败？GTID 和认证插件是高频雷区
MySQL 8.0+ 导出到 5.7，或用旧版 myloader 连 8.0+，大概率卡死或报错，不是配置问题，是协议/元数据不兼容。
- 源库是 MySQL 8.0+，导出时必须加：
--no-gtids --no-binlogs，否则metadata文件里写入 GTID 位点，myloader在 5.7 上解析失败，报ERROR 1840 (HY000) - 确认
myloader版本 ≥v0.10.0，否则无法处理caching_sha2_password认证，连接日志只显示 “Connected to MySQL server” 然后挂住 - 结构和数据建议分开导：
--no-schemas导纯数据，结构用mysqldump --no-data单独导，避免 AUTO_INCREMENT 冲突
导出一致性被破坏？--single-transaction 不是万能开关
--single-transaction 只对 InnoDB 表生效，且依赖隔离级别和长事务状态。线上库稍有不慎，导出就是“半新鲜半陈旧”的混合快照。
- 导出前查活跃长事务：
SELECT TRX_ID, TRX_STARTED FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 1，超 30 秒的先干掉 - MyISAM 表必须用
--lock-all-tables（停写）或接受非一致性，--single-transaction对它完全无效 - 源库开了
read_only=OFF且有未提交事务时，快照可能被阻塞或读到部分新数据 - 校验导出完整性：
mydumper --check -o /path/to/dump，别等导入完才发现缺 chunk
实际提速的关键不在堆线程数，而在让每个线程真正“有活干”：有主键可切、有 chunk 可分、有权限可跳过校验、有干净环境可绕过 binlog 和 GTID。漏掉其中一环，-t 32 也跑不满。
