mysqldump本质是单线程工具，不支持--threads等并发参数，其逐表select→sql格式化→写入文件的固定流程无法通过参数优化突破；提速必须换用mydumper、mysqlpump或xtrabackup等多线程/物理备份工具。
mysqldump 本质是单线程工具，它不切分数据、不并行读表、也不并发写文件——这不是参数能改的限制，而是设计决定的。想靠 --threads 或 --parallel 加速？直接报错 unknown option '--threads'。
为什么 mysqldump 备份大库就是慢
它执行流程固定：连库 → 查一个表结构 → 全表 SELECT → 格式化成 INSERT → 写入文件 → 下一个表。哪怕加了 --quick 或 --single-transaction，也只是缓解内存或一致性问题，无法突破单连接、单结果集流式读取的瓶颈。
- IO wait 高但 CPU 闲置：磁盘在狂读，CPU 等着拼 SQL，资源严重错配
- 导出亿级表耗时数小时，中途易触发
MySQL server has gone away（max_allowed_packet或网络超时） - 生成的 SQL 默认每行一条
INSERT，没开--extended-insert的话，导入时效率暴跌 3–4 倍 - 8.0 默认开启
performance_schema和innodb_doublewrite，逻辑读响应延迟比 5.7 高 15%~40%
哪些“提速参数”其实不提速
这些常被误认为能开并发或加速的选项，实际和线程数完全无关：
-
--max_allowed_packet=1G：只是放宽单条语句或结果集大小，防报错，不提速 -
--compress：压缩客户端/服务端传输流，降低网络带宽压力，但压缩本身仍是单线程串行 -
--skip-lock-tables：跳过锁表，减少阻塞，对只读从库有用，但不改变读取速度 -
--hex-blob：纯格式转换，防止 BLOB 乱码，无性能增益
全加上，它还是只用 1 个线程读、1 个线程写、1 个线程格式化。
真正破局：换工具，不是调参数
面对 GB/TB 级数据，必须切换底层模型。三种主流替代方案按推荐顺序：
-
mydumper（首选）：开源成熟，支持分片（-r 500000）、压缩（--compress）、断点续传；线程数建议设为物理核数的 1.2~1.5 倍（如 12 核用-t 14）；注意需提前授权FILE权限并配置secure_file_priv -
mysqlpump（官方替代）：MySQL 5.7.8+ 自带，多线程默认启用；命令形如mysqlpump --user=root --databases db1 --threads=4；不支持--where，想导部分数据得先建临时表 - Percona XtraBackup：物理热备，对 IO 更友好，但要求
innodb_file_per_table=ON，且云厂商托管 MySQL 常限制其权限模型
别在 mysqldump 上死磕——它不是慢，是根本没设计成干这活的。
