--quick 有用但仅缓解客户端内存压力，不降低服务端开销；需配合 --single-transaction 使用，对 myisam 效果有限，且无法解决 routine、events 等元数据导致的内存问题。
mysqldump 内存爆满时 --quick 真的有用吗
有用，但只在特定场景下起效——它解决的是客户端内存堆积，不是服务端内存压力。当你用 mysqldump 备份大表（比如几千万行的 orders 表），默认会把整张表查出来缓存在客户端内存里再写入文件，这时候 OutOfMemoryError 或进程被 OOM killer 干掉，就是典型症状。
加 --quick 后，mysqldump 会逐行 fetch，边读边写，客户端内存占用基本恒定在几 MB 级别。但它不减少服务端查询开销，InnoDB 仍需构建完整结果集并维持事务一致性视图。
-
--quick必须配合--single-transaction使用才安全（否则可能遇到 inconsistent dump） - 对 MyISAM 表，
--quick效果有限，因为 MyISAM 不支持快照读，且锁表期间无法流式输出 - 如果服务端本身内存吃紧（比如
innodb_buffer_pool_size配得太小），--quick无法缓解 —— 这是常见误判点
什么时候该换 --skip-extended-insert 而不是只靠 --quick
恢复阶段卡住、导入慢、MySQL 客户端报 Packet too large，往往不是备份时内存问题，而是还原时单条 SQL 太长导致的。默认 mysqldump 用 extended insert（一条 INSERT 插多行），生成的 SQL 文件里动辄一行几 MB。
这时加 --skip-extended-insert，让每行数据单独成一条 INSERT，虽然文件体积翻倍，但导入更稳定、可中断、内存压力分散。
- 和
--quick可同时使用，互不冲突 - 备份时间略增（客户端拼接 SQL 开销变大），但通常可忽略
- 若后续要用
mysqlpump或mydumper，它们默认就按 chunk 分发，无需手动加这个参数
--quick 在管道场景下容易被忽略的副作用
直接 mysqldump --quick db tbl | gzip > backup.sql.gz 看似合理，但一旦网络抖动或接收端卡住（比如磁盘写满），MySQL 服务端会因 TCP 窗口阻塞而 hang 住整个连接，进而拖慢甚至卡死其他查询 —— 尤其在低配服务器上。
这不是 --quick 的 bug，而是流式传输缺乏背压控制的表现。
- 加
--compress不能缓解这个问题，反而可能加重 CPU 压力 - 更稳妥的做法是先 dump 到本地磁盘（哪怕只是
/dev/shm），再压缩传输 - 若必须走管道，建议加
--max-allowed-packet=64M并确保两端网络 buffer 足够，避免频繁重传
真正压垮内存的，往往是没关的额外功能
很多人加了 --quick 还崩，回头一看日志发现：dump 过程中启用了 --routines + --events + --triggers，而数据库里有上百个复杂存储过程，mysqldump 会先把所有 routine 的 CREATE 语句全 load 到内存再输出 —— 这部分完全绕过 --quick 控制。
同理，--all-databases 遇到大量小库时，库名、字符集、排序规则等元数据也会累积占用可观内存。
- 只 dump 必要库表，用
-B db1 db2显式指定，比--all-databases更可控 - 确认是否真需要 routines/events：生产环境多数时候只需表结构+数据
- 如果必须导出 routine，考虑分批 dump：
mysqldump --quick --routines db1 > db1_routines.sql单独处理
内存问题从来不是单一参数能兜底的事。--quick 只管客户端读取姿势，服务端资源、网络链路、元数据规模、甚至终端 shell 的 ulimit 设置，都可能成为最后一根稻草。调参前先看 top 和 SHOW PROCESSLIST，分清到底是哪一环在喘不过气。
