是，mysqldump默认不加--quick时会将整张表缓存到客户端内存再写入，易OOM；加--quick后改用逐行流式导出，内存稳定在KB级，但需配合--single-transaction或--lock-tables保证一致性。
mysqldump导出慢，是不是没加 --quick？
默认情况下，mysqldump 会把整张表查出来缓存在客户端内存里，再一次性写入文件——对大表（比如几千万行）来说，这不仅吃光内存，还可能触发 OOM 或卡死连接。加 --quick 后，它改用逐行 mysql_use_result() 模式，边查边写，内存占用稳定在 KB 级别。
但注意：--quick 不是万能加速键。它只解决“内存堆积”问题，不提速网络或磁盘 I/O；如果导出目标是远程 MySQL，且网络延迟高，反而可能因频繁小包变慢。
-
--quick必须搭配--single-transaction（InnoDB）或--lock-tables（MyISAM）用，否则可能导出不一致数据 - MySQL 5.7+ 默认启用
--quick，但老版本或某些封装脚本可能显式关掉它，得手动确认 - 若导出时看到
Lost connection to MySQL server during query，大概率是没加--quick导致服务端 kill 了长查询
--net_buffer_length 和 --max_allowed_packet 怎么配才不翻车？
这两个参数控制通信缓冲区大小，直接影响单次网络包体积和传输次数。--net_buffer_length 是客户端每次发/收的默认包长（默认 1MB），--max_allowed_packet 是服务端允许的最大单包（默认 64MB）。导出大字段（如 TEXT、BLOB）时，若单行超 --net_buffer_length，mysqldump 会自动扩容，但频繁扩容有开销；若超 --max_allowed_packet，直接报错 Packets larger than max_allowed_packet are not allowed。
- 建议统一设为相近值，例如：
--net_buffer_length=4M --max_allowed_packet=64M - 不要盲目调高
--net_buffer_length到 64M：过大会导致小表导出反而多占内存、延迟首字节输出 - 修改后必须重启 MySQL 服务端才能生效
--max_allowed_packet，但客户端参数（如--net_buffer_length）只需加在命令行里
导出速度上不去？检查这三个隐藏瓶颈
加了 --quick 和调参后仍慢，问题往往不在 mysqldump 本身，而在上下游链路：
- 源库负载高：
SHOW PROCESSLIST看是否有其他长事务阻塞SELECT，特别是用了--single-transaction时，MVCC 快照依赖最老活跃事务 - 目标磁盘慢：导出到 NFS 或机械盘，
iotop -p $(pgrep mysqldump)能看出写入速率是否卡在 10MB/s 以下 - 字符集转换开销：如果库是
utf8mb4但终端 locale 是C，mysqldump会反复做编码检测。加--default-character-set=utf8mb4显式声明可避免
一个稳妥的高性能导出命令模板
适用于 InnoDB 表、GB 级数据、本地或低延迟网络环境：
mysqldump --defaults-file=/etc/mysql/debian.cnf \ --single-transaction \ --quick \ --no-autocommit \ --skip-triggers \ --default-character-set=utf8mb4 \ --net_buffer_length=2M \ --max_allowed_packet=256M \ --hex-blob \ mydb mytable > mytable.sql
其中 --no-autocommit 减少事务提交次数，--hex-blob 避免二进制字段解析出错，--skip-triggers 防止导出触发器定义干扰还原逻辑。真正要注意的是：这些参数组合在不同 MySQL 版本间行为略有差异，尤其是 --single-transaction 在有 DDL 进程时可能失效，得结合业务窗口期判断是否敢用。
