mydumper 备份更快的核心在于多线程与逻辑分片：默认4线程可调，支持按表或行切分任务并行导出，提升io和cpu利用率；但仍是逻辑备份，恢复不快，且依赖secure_file_priv等配置。
mydumper 备份比 mysqldump 快在哪？
核心就两点：多线程 + 逻辑分片。mysqldump 是单线程导出，锁表或一致性读期间整个库卡着；mydumper 默认启动 4 个线程（可调），按表甚至按行（配合 --chunk-filesize）切分任务，IO 和 CPU 并行压上去，尤其对大表效果明显。
但要注意：它不替代物理备份，仍是逻辑备份，恢复时仍要走 SQL 解析执行，大库恢复未必“快”——只是备份阶段快。
-
mydumper会为每张表生成独立的.sql文件，还附带metadata记录 GTID 或 binlog 位置，这对基于位点恢复很关键 - 不支持视图、存储过程、函数的原子级事务导出（它们被单独导出，没包在事务里），跨库依赖容易断
- 默认用
SELECT ... INTO OUTFILE方式拉数据，要求 MySQL 开启secure_file_priv且目录可写，否则直接报错Access denied for SELECT ... INTO OUTFILE
怎么调参让 mydumper 真正跑满资源？
默认 4 线程太保守，尤其在 SSD + 多核机器上，往往只吃 20% CPU。关键参数就三个：-t（线程数）、-r（行级分片粒度）、--chunk-filesize（按大小切片）。
-
-t 8或-t 12更常见，但别盲目堆高——超过 CPU 核心数太多反而因上下文切换拖慢整体速度 -
-r 1000000对千万级表有效，但对小表（--skip-tz-utc 避免每个 INSERT 都带时区转换 -
--chunk-filesize 50（单位 MB）能强制大表拆成多个文件，避免单文件过大导致 OOM 或网络传输失败，但会多出几十个文件，后续恢复得靠myloader自动识别 - 务必加
--no-schemas或--no-data来分离结构和数据，调试时先试一个表：mydumper -B test -T t1 -o /tmp/dump/
myloader 恢复失败常见报错及绕过方法
myloader 不是“一键还原”，它按文件并行导入，但遇到外键、自增冲突、字符集不一致时会静默失败或卡住。
- 报错
ERROR 1215 (HY000) at line 1: Cannot add or update a child row: a foreign key constraint fails：说明子表数据先于父表导入。加--disable-foreign-keys（默认已开），或确保mydumper导出时用了--order-by-primary - 导入后自增 ID 乱跳？因为
myloader默认不重置 AUTO_INCREMENT，加--enable-binlog会让它跳过 SET INSERT_METHOD=NO，但更稳妥的是恢复后手动ALTER TABLE t1 AUTO_INCREMENT = N - 中文变问号？导出时没指定
--default-character-set=utf8mb4，或 MySQL server 端character_set_server不是utf8mb4，光改客户端没用 - 恢复中途断了？
myloader不支持断点续传，但文件是独立的，删掉已成功导入的表对应文件，再重跑即可
哪些场景下 mydumper 反而不如 mysqldump？
不是所有“快”都值得换。小库（mydumper 的并发模型反而添乱。
- 备份过程中有长事务或未提交 DML，
mydumper的一致性快照依赖START TRANSACTION WITH CONSISTENT SNAPSHOT，但该语句在READ-COMMITTED隔离级别下可能不生效，导致部分表数据不一致 - MySQL 版本 innodb_locks_unsafe_for_binlog，
mydumper可能无法获取全局一致性位点，metadata里的 binlog 坐标不可信 - 用 Percona XtraDB Cluster 或 Group Replication 时，
mydumper的多线程 SELECT 可能触发流控（flow control），拖慢整个集群，这时老老实实用mysqldump --single-transaction更稳
真正要发挥 mydumper 价值，得同时管好 MySQL 的 IO 调度、buffer pool、以及备份目标磁盘的随机写能力——工具快，不代表整个链路快。
