mysqldump在亿级数据下天然慢，因其单线程串行构造sql、锁表久、内存压力大，无法靠参数调优根本解决；应改用mysqlpump（mysql 5.7+多线程并行导出）或mydumper（更成熟，支持分片、压缩、断点续传）。
mysqldump 在亿级数据下天然慢，别硬扛——它单线程、锁表久、内存吃紧，不是调几个参数就能救回来的。真正提速得换思路：要么用 MySQL 5.7+ 自带的 mysqlpump（多线程 + 并行导出），要么直接上 mydumper（更成熟、更可控）。
为什么 mysqldump 导出上亿数据就是慢？
它本质是“串行构造 SQL”：连上库 → 读表结构 → 逐表查数据 → 拼 INSERT 语句 → 写文件。哪怕加了 --quick 或 --single-transaction，也改不了单连接、单结果集流式读取的瓶颈。IO 瓶颈卡在磁盘写入，CPU 却常闲置；大事务下 innodb_buffer_pool 压力大，还容易触发 long query kill 或超时中断。
常见错误现象包括：
- 导出耗时数小时，
top显示 mysqldump 进程 CPU 不高但 IO wait 高 - 导出中途报错：
MySQL server has gone away（max_allowed_packet或网络超时） - 目标库导入时卡住，因为导出的 SQL 文件里全是单行
INSERT，没合并（缺--extended-insert）
mysqlpump 能快多少？怎么用才不翻车？
mysqlpump 是 MySQL 官方在 5.7.8 引入的替代工具，核心优势是默认多线程（每个表一个线程）、支持并行导出结构和数据、可按库/表粒度控制并发。
实操建议：
- 必须用 MySQL 5.7.8+，低版本没有这个命令
- 基础命令：
mysqlpump --user=root --password --host=localhost --databases db1 db2 --threads=4 > backup.sql - 导出单库多表时，加
--include-tables=table_a,table_b比全库 dump 更稳 - 避免导出视图或存储过程引发权限问题：显式加
--skip-dump-views --skip-dump-routines - 它不支持
--where条件筛选，想导部分数据得先建临时表再 dump
性能影响：4 线程通常比 mysqldump 快 2–3 倍；但线程数不是越多越好，超过 CPU 核心数易引发锁争用，反而拖慢。
mydumper 为什么更适合生产环境的亿级导出？
mydumper 是 Percona 开发的独立工具，比 mysqlpump 更早、更成熟，专为海量数据设计。它把导出拆成「结构文件 + 多个数据分片文件」，支持断点续传、压缩、一致性快照（依赖 FLUSH TABLES WITH READ LOCK 或 --no-locks + --trx-consistency-only），且导入端 myloader 也能并行。
关键配置项：
- 导出命令示例：
mydumper -u root -p pass -B mydb -o /backup/ --threads=8 --compress --chunk-filesize=64 -
--chunk-filesize控制每份数据文件大小（MB），避免单文件过大难传输 - InnoDB 表推荐加
--no-locks（靠 MVCC 实现一致性），MyISAM 必须加--lock-all-tables - 导出后目录里会有
metadata文件，记录 binlog 位置，可用于主从同步点对齐
容易踩的坑：
- 没装
libmysqlclient依赖，运行时报error while loading shared libraries - 导出用户缺少
RELOAD、LOCK TABLES权限，报错Access denied; you need (at least one of) the RELOAD privilege(s) - 误用
--long-query-guard设太小（如 10 秒），导致长查询被 kill，导出中断
什么时候还该坚持用 mysqldump？
不是所有场景都要上重型工具。以下情况 mysqldump 依然够用且更稳妥：
- 导出量在百万行以内，且对停机窗口不敏感
- 目标库版本老旧（mysqlpump，又不想引入第三方二进制
- 需要保留完整注释、DELIMITER、存储过程逻辑，
mydumper对 routine 支持弱 - 导出后要人工审阅 SQL（比如合规审计），
mysqldump输出最标准、最易读
此时优化重点是参数组合：--single-transaction --skip-triggers --compact --extended-insert --quick --net-buffer-length=1M，再配合 --where 精准切片，比盲目堆线程更实际。
真正棘手的是跨 TB 级导出——这时候工具只是入口，你得盯住磁盘 IOPS、网络吞吐、目标端恢复能力。选 mysqlpump 还是 mydumper，不取决于谁名字新，而在于你能否控制它的锁行为、中断恢复逻辑和输出格式适配性。
