-t应设为cpu物理核心数的1.2~1.5倍（如16核配-t 20），超24后收益下降；需联动-r分片（千万级表-r 1000000，亿级表-r 500000），并确保file权限、secure_file_priv配置及目录属主正确。
mydumper 的 -t 参数到底该设多少
线程数不是越大越好，盲目设成 -t 32 或 -t 64 反而会让备份变慢。实测在 SSD + 16 核物理 CPU 的机器上，-t 4 时 CPU 利用率长期卡在 15%~20%，IO 也远未吃饱；而调到 -t 14（≈12 核 × 1.2）后，CPU 和磁盘吞吐才真正跑起来。
推荐值按物理核心数计算，不是逻辑线程数（即不看超线程）：
-
-t建议设为物理核心数的 1.2~1.5 倍（如 8 核 →-t 10，16 核 →-t 20） - 超过 24 后收益明显下降，上下文切换开销反超收益
- 若备份目标是 HDD，
-t超过 8 就容易引发 IO 争抢，建议 ≤6
线程数和分片粒度必须联动调优
只调 -t 不调 -r，等于给多辆车修了一条窄路——线程再多，也会堵在单个大 chunk 上。mydumper 按主键范围分片，-r 控制每 chunk 行数，直接影响线程是否能并行干活。
常见分片建议：
- 千万级表（10M~50M 行）：用
-r 1000000 - 亿级表（>100M 行）：压到
-r 500000，避免单 chunk 扫描太久阻塞其他线程 - 若表无主键或主键稀疏，
-r失效，此时应优先补主键或改用--chunk-filesize 50
为什么加了 -t 还是单线程在跑
最常见原因是权限或配置没对齐，线程根本启不起来。现象是日志里只有 1 个 worker 在干活，CPU 占用纹丝不动。
重点排查这几项：
- 确认备份用户有
FILE权限：GRANT FILE ON *.* TO 'u_mydumper'@'%';（漏掉这条，mydumper 会自动退化为单线程模拟模式） - 检查
secure_file_priv是否为空：SELECT @@secure_file_priv;返回NULL或空字符串就必须重启 MySQL 并配路径 - 目标输出目录属主必须是
mysql用户：chown mysql:mysql /data/backup/mydumper_bak - 若用 socket 连接（
-S），确保mysql用户对 socket 文件有读写权限
线程数影响恢复阶段的 myloader 表现
很多人只调备份线程，忘了 myloader 默认也是单线程恢复——备份再快，恢复卡住一样拖整体节奏。别指望它自动继承 mydumper 的 -t 值。
恢复时务必显式指定线程：
-
myloader -u ... -d ./backup/ -t 8（-t在 myloader 中同样生效） - 注意：恢复线程数不宜超过目标库的写入能力，InnoDB 缓冲池小或磁盘慢时，
-t 16可能引发大量锁等待 - 若恢复报
Lock wait timeout exceeded，先降-t到 4，再观察
真正卡点不在参数本身，而在物理资源与逻辑分片的匹配——线程数只是调度器，-r 和 secure_file_priv 才决定它有没有活干、能不能并行干。
