不是加--quick就能解决，真正瓶颈常是/tmp满、服务端缓冲池不足或管道卡死；--quick仅优化客户端内存，对服务端oom、tmpfs空间耗尽、myisam锁表等无效，须优先检查/tmp空间、inode、临时目录及僵尸文件。
直接结论：不是加 --quick 就能解决，真正要命的往往是 /tmp 满、服务端缓冲池扛不住、或管道卡死导致连接 hang 住。
为什么 --quick 经常没用
它只改客户端读取行为：默认把整张表结果集全拉进内存再写；加了之后变成逐行 mysql_fetch_row()，客户端内存压到几 MB。但以下情况它完全不生效：
- 服务端仍在构建完整一致性视图（
InnoDB的READ COMMITTED或快照事务），innodb_buffer_pool_size配太小，服务端自己先 OOM -
/tmp是tmpfs（内存挂载），大表导出先落盘再压缩，df -h /tmp显示 100% 就会报 “Cannot allocate memory”——其实是磁盘空间不足 - 库中有上百个存储过程，又用了
--routines，mysqldump会一次性加载全部定义拼 SQL，这部分不走流式逻辑 - 表是
MyISAM，锁表期间无法流式输出，--quick基本无效
必须优先检查的三个地方
别急着改参数，先确认瓶颈在哪：
- 运行
df -h /tmp和df -h（看备份路径所在分区），再补一句df -i /tmp——小文件多时 inode 可能先耗尽 - 查 MySQL 实际用哪个临时目录：
SELECT @@tmpdir, @@innodb_tmpdir;；若指向/tmp且空间小，加--tmpdir=/data/tmp显式指定大分区 - 执行
lsof +L1，看有没有已删未释放的大日志或临时文件占着空间（常见于mysqldump卡住后被 kill）
--single-transaction 必须和 --quick 配合用
单独用 --single-transaction 不降内存，它只是开一个一致性快照事务；但不用 --quick，客户端仍会把整个快照结果缓存在内存里。两者合体才安全：
-
InnoDB表有效；MyISAM不支持快照，此时必须用--lock-all-tables，但会阻塞写入 - 导出含
VIEW或ROUTINE时，额外加--skip-triggers --skip-routines --skip-events，避免元数据堆积 - 若导出后要压缩，别直接管道：
mysqldump --quick db | gzip > backup.sql.gz看似省空间，实则危险——接收端（如gzip）一旦卡住，MySQL 连接会 hang，拖慢甚至卡死其他查询
更稳的导出流程
先落地，再处理：
- 用
--tmpdir=/dev/shm（如果内存够）或大分区路径，确保中间文件有地方写 - 导出到本地磁盘：
mysqldump --quick --single-transaction --skip-routines --skip-triggers db > backup.sql - 再分步压缩：
gzip backup.sql，或传输前校验：sha256sum backup.sql - 非走管道不可？至少加
--max-allowed-packet=64M并确认net_buffer_length足够，减少重传压力
真正容易被忽略的是：/tmp 分区是否为 tmpfs、lsof +L1 是否真清掉了僵尸临时文件、以及 MyISAM 表根本不能靠 --quick 流式导出——这些点一漏，调再久参数也没用。
