千万级数据用mydumper备份时，-t 8至-t 16线程最稳；超16后因全局锁排队、I/O争抢和内存压力，耗时反增且失败率上升，推荐-t 12配合--less-locking、-r 500000、--compress及严格库过滤。
直接上结论：千万级数据用 mydumper 备份，线程数不是越多越好，-t 8 到 -t 16 是更稳的选择；盲目开 -t 32 反而可能因锁争用、I/O 或内存抖动导致整体耗时上升甚至失败。
为什么不能无限制增加 -t 线程数
线程数本质是并发 dump 表的数量，但 MySQL 的锁机制和 I/O 能力存在隐性瓶颈：
-
mydumper对非事务表（如MyISAM）仍需FLUSH TABLES WITH READ LOCK，该锁是全局的，所有 dump 线程必须排队等待它释放 —— 线程越多，排队越长，反而放大阻塞 - 每个线程会独立建立连接、启动事务、读取数据页，线程数过高易触发
max_connections限制或内存溢出（尤其当--statement-size较大时） - 磁盘 I/O 成为瓶颈后，多线程争抢读写头，随机 IO 效率反低于适度并发下的顺序读取
- 实测某 120GB、单表 4000W 行的订单库，在 24 核机器上
-t 16比-t 32快 23%，且失败率为 0 vs 17%
千万级场景下推荐的 mydumper 启动参数组合
兼顾速度、稳定性与恢复可用性，不堆线程，而是优化关键行为：
- 用
-t 12（而非默认4）平衡 CPU 利用率和锁排队压力 - 加
--less-locking：让MyISAM表在获取 FTWRL 后尽快释放，InnoDB 表全程走一致性快照，减少锁持有时间 - 设
-r 500000：对大表按行切片（每片约 50 万行），避免单文件过大、导入时 OOM 或中断重跑成本高 - 启用
--compress+--compress-protocol：压缩传输层和文件层，节省磁盘空间并降低网络/IO 压力（注意 CPU 占用会上升 10%~15%） - 过滤系统库必须加
--regex '^(?!(mysql\.|sys\.|information_schema\.|performance_schema\.))'，否则备份中混入系统表会导致myloader恢复报错
完整命令示例：
mydumper -u backup_user -p 'xxx' -h 127.0.0.1 -P 3306 \ -t 12 --less-locking -r 500000 --compress --compress-protocol \ --regex '^(?!(mysql\.|sys\.|information_schema\.|performance_schema\.))' \ -o /backup/million_db_$(date +%Y%m%d)
备份后必须验证的三个关键点
千万级备份耗时长，出错再重跑代价高，导出完成后别急着删源文件：
- 检查
metadata文件是否存在且含有效 binlog 位置：cat /backup/.../metadata | grep -E "(Finished|Binlog_Position)" - 确认各表的
.sql和.csv（如有）文件数量匹配，缺失即代表某线程中途退出，常见于超时或权限不足 - 抽查一个大表的
schema.sql是否含CREATE TABLE，且data.sql开头有INSERT INTO `xxx` VALUES—— 若只有INSERT IGNORE（由-N引入），恢复时需确保目标库为空，否则数据会丢失
真正卡住人的从来不是“能不能并行”，而是并行之后锁怎么放、文件怎么切、元数据怎么验。线程数调到 16 以上前，先看 SHOW PROCESSLIST 里有没有大量 Waiting for table flush —— 有，就说明你在跟锁打架，而不是跟时间赛跑。
