mysqldump --quick 仅优化客户端逐行读取以降低内存占用，但对服务端一致性视图构建、tmpfs空间不足、存储过程加载、MyISAM锁表等场景完全无效；需优先检查/tmp和备份分区的磁盘与inode使用率、MySQL临时目录配置及大文件残留。

mysqldump --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，客户端仍会把整个快照结果缓存在内存里。两者合体才安全：

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• InnoDB 表有效；MyISAM 不支持快照，此时必须用 --lock-all-tables，但会阻塞写入
• 导出含 VIEW 或 ROUTINE 时，额外加 --skip-triggers --skip-routines --skip-events，避免元数据堆积
• 非走管道不可？至少加 --max-allowed-packet=512M，否则网络缓冲区撑爆，报错 Lost connection to MySQL server during query

更稳的导出流程

先落地，再处理：

• 用 --tmpdir=/dev/shm（如果内存够）或大分区路径，确保中间文件有地方写
• 导出到本地磁盘：mysqldump --quick --single-transaction --skip-routines --skip-triggers db > backup.sql
• 再分步压缩：gzip backup.sql，或传输前校验：sha256sum backup.sql

真正卡死的点往往不在 SQL 生成逻辑，而在临时目录空间、服务端 buffer 配置、或者管道接收端 hang 住导致连接僵死——这些地方一漏，加再多 --quick 都白搭。