根本原因是mysqldump客户端默认用mysql_store_result将整表结果全载入内存导致OOM；加--quick启用流式读取可压至几MB，但必须配套--single-transaction防锁表、--skip-extended-insert防语句超限，且需排查/tmp空间、MyISAM锁表及管道卡死等无效场景。
不是 MySQL 服务端内存暴涨，是 mysqldump 客户端自己把整张表结果全读进内存，然后崩的——加 --quick 就能压到几 MB，但只加它还不够，漏掉配套参数照样翻车。
mysqldump 默认走 mysql_store_result 模式，整表塞内存
默认行为是服务端发完全部结果，mysqldump 一次性接收、缓存、再拼 SQL。1000 万行 × 平均每行 2KB，光原始数据就 20GB，还没算字符串对象头和 Python/内部开销。这不是服务端 OOM，是客户端进程 RSS 持续飙升，最后被系统 oom-killer 杀掉。
-
mysqldump进程本身被 kill，不是mysqld；dmesg -T | grep "killed process"里看到的mysqldump才是真凶 - 哪怕导空表，旧版客户端仍会预分配固定缓冲区（如 64MB），跟数据量无关
-
innodb_buffer_pool_size再大也救不了——这是服务端缓存，不参与客户端结果集加载
必须配齐 --quick + --single-transaction + --skip-extended-insert
--quick 只解决“读取方式”，但导出过程还可能因其他环节二次崩溃：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
--quick启用mysql_use_result流式读取：逐行mysql_fetch_row()，内存恒定在几 MB -
--single-transaction对 InnoDB 表开一致性快照，避免锁表；不加它，--quick仍可能因锁表+全量读双重加压 -
--skip-extended-insert禁用多值 INSERT（如INSERT INTO t VALUES (1),(2),(3)），防止单语句超max_allowed_packet导致中断——这个参数调再大也没用，只要没加--skip-extended-insert，照样失败
这些情况 --quick 完全无效
别以为加了 --quick 就万事大吉。以下场景它不生效，OOM 依旧发生：
-
/tmp是 tmpfs（内存挂载），导出中间文件落盘失败，报 “Cannot allocate memory” —— 实际是磁盘空间或 inode 耗尽：df -h /tmp和df -i /tmp必须先查 - 用了
--routines或--events，存储过程、函数、事件定义会被一次性加载拼 SQL，这部分不走流式逻辑 - 表是 MyISAM：
--quick基本失效，锁表期间无法流式输出；此时只能用--lock-all-tables，但会阻塞写入 - 导出管道卡住：
mysqldump --quick db | gzip > backup.sql.gz中，若gzip缓冲慢或卡死，MySQL 连接会 hang 住，拖垮服务端连接池
真正容易被忽略的点
很多人盯着 mysqldump 参数调，却忘了它只是个客户端工具——它的行为完全独立于 MySQL 服务端内存配置。OOM 的根因永远在驱动层是否流式，而不是“数据太大”。更隐蔽的是：--tmpdir 默认指向 /tmp，而很多容器或国产 OS（如银河麒麟）的 /tmp 是内存挂载，4GB 容器限制下，一个 3GB 的中间 SQL 文件就能直接撞穿 cgroup 内存上限，连 dmesg 都会显示 CONSTRAINT_CGROUP。
