mydumper默认-t 4拖慢大库备份，因无法充分利用ssd与多核资源；应按cpu物理核心数1.2~1.5倍设-t值（如12核用-t 14），配合-r分片、--compress压缩、--secure_file_priv配置及file权限授权，才能真正释放并发性能。
mydumper 默认线程数 -t 4 在现代服务器上反而拖慢备份，真正提速必须手动调参——不是开更多线程就行，而是让线程数、分片粒度、压缩和权限四者对齐。
怎么设 -t 值才不浪费 CPU 和 SSD？
mydumper 的并发瓶颈常不在 SQL 层，而在 IO 调度与上下文切换。盲目堆线程会适得其反：
- 物理核心数 ≤ 8：用 -t 8～-t 10 即可，再高收益极低
- 物理核心数 12～16：推荐 -t 14～-t 18（1.2～1.5 倍）
- 物理核心数 ≥ 24：超过 -t 24 后实测耗时基本持平，甚至因锁竞争上升
- SSD 阵列 + NVMe 盘时，-t 值可比 HDD 环境高 20%～30%，但需配合 -r 调整分片
-r 分片太粗或太细都会卡住大表
-r 控制每 chunk 扫描的行数，直接影响单线程负载均衡和内存占用：
- 千万级表（10M～50M 行）：设 -r 1000000（100 万行/块），避免单 chunk 超 30 秒
- 亿级表（>100M 行）：压到 -r 300000～-r 500000，否则一个 chunk 拖太久，其他线程早空闲了
- 若表有明显热点（如时间字段倾斜），-r 过小会导致大量小文件+频繁 seek，反而伤 SSD 寿命
- 不要混用 -r 和 --chunk-filesize：前者按行切，后者按字节切，冲突时以 --chunk-filesize 为准（推荐设为 --chunk-filesize 50，单位 MB）
Access denied for SELECT INTO OUTFILE 报错根本原因在哪？
这个报错不是权限没给全，而是mydumper 底层强依赖 MySQL 的 SELECT INTO OUTFILE 能力，但默认被关死：
- 先查 SELECT @@secure_file_priv;：返回 NULL 或空字符串 = 功能禁用，必须重启 MySQL 并在配置中显式设 secure_file_priv = /data/backup/mydumper_bak
- 目标路径必须属主为 mysql 用户：chown mysql:mysql /data/backup/mydumper_bak
- 备份用户必须有 FILE 权限：GRANT FILE ON *.* TO 'u_mydumper'@'%';（仅 SELECT 不够）
- 若无法改 secure_file_priv（如云数据库 RDS），只能退到 --no-schemas --no-data 先验证连通性，再换方案
恢复时外键失败或 metadata 位点不准怎么办？
myloader 不处理约束和 binlog 位点偏移，这两处最容易翻车：
- 恢复前务必执行 SET FOREIGN_KEY_CHECKS=0;，否则遇到外键引用缺失表直接中断
- metadata 文件里记录的是备份**开始时刻**的 binlog pos，不是结束时刻；若备份耗时 >5 分钟，该位置已滞后，做 PITR 时得手动执行 SHOW MASTER STATUS 校准
- 对含视图、存储过程的库，mydumper 不保证跨库依赖一致性，需额外用 mysqldump -d -n -t db1 view_name 单独导出结构
- 非事务表（MyISAM）备份期间仍可能被写入，mydumper 用 FTWRL 锁但释放早，长事务下仍有风险，建议业务低峰期操作
最常被忽略的一点：--compress 不是锦上添花，而是关键提速项——gzip 压缩后 IO 总量下降 60%，实际耗时往往比不压缩还短，尤其走网络传输或对象存储时。
