mysqldump还原触发OOM是因为MySQL解析超长INSERT、未禁用autocommit及触发器加载导致内存堆积；需改用--skip-extended-insert、SET autocommit=0等优化并重启MySQL释放sp_head内存。
逻辑还原（mysqldump + mysql 导入）过程触发 OOM，不是因为 SQL 本身错，而是还原时 MySQL 一次性加载大事务、大 BLOB 或未分块的 INSERT 批次，把 sp_head::main_mem_root 和连接级缓冲撑爆。直接调 innodb_buffer_pool_size 治标不治本。
为什么 mysqldump 还原会吃光内存？
还原不是“执行 SQL”，而是 MySQL 解析每条语句、构建执行上下文、缓存游标/触发器/SP 对象——尤其当 dump 文件含大量单条超长 INSERT（如含 JSON/BLOB）、或未禁用 autocommit 时，事务日志 + 行锁 + 内存表结构全堆在单个连接里：
-
mysqldump --extended-insert默认生成超长单行 INSERT，MySQL 解析时需整行载入内存再拆解，10MB 的 INSERT 行可能占 50MB+ 内存 - 还原脚本没设
SET autocommit=0，每个 INSERT 都开新事务，undo log + 锁结构持续累积 - 目标库有触发器/函数，每次 INSERT 触发一次
sp_head实例加载，而table_open_cache_instances默认为 16，每个实例都缓存一遍触发器元数据 → 内存 ×16 -
max_allowed_packet设得过大（如 1G），MySQL 会预分配对应 buffer，但实际只用几 KB，浪费严重
还原前必须做的三件事
别等导入一半被 kill，先改 dump 文件和导入方式：
- 重导出时加
--skip-extended-insert：每行一个 INSERT，避免单语句内存爆炸；若必须用 extended，加--net-buffer-length=64K控制解析缓冲上限 - dump 文件开头插入：
SET autocommit=0; SET unique_checks=0; SET foreign_key_checks=0;；结尾加COMMIT;，把所有 INSERT 包进一个事务（注意：仅适用于无主键冲突/唯一约束的干净库） - 确认目标库已关掉无关功能：
SET GLOBAL query_cache_type = 0;（MySQL 5.7），并临时设table_open_cache_instances = 1（防触发器内存翻倍）
导入时用 mysql 客户端参数限流
客户端不是旁观者，它传语句的方式直接影响服务端内存压力：
- 用
mysql --max-allowed-packet=64M --net-buffer-length=64K -u root -p ，强制限制单次网络包和内部 buffer，避免服务端预分配过大空间 - 禁止用
source dump.sql在 MySQL shell 里执行——shell 会额外缓存历史命令 + 语法树，比直连客户端多占 20%+ 内存 - 如果 dump 超过 1GB，拆成多个文件，用循环导入：
for f in *.sql; do mysql -u root -p db_name ，每次连接独享内存，旧连接释放干净
查漏：还原后立刻检查 sp_head 泄漏
即使还原成功，若中途报过错或中断过，sp_head::main_mem_root 可能残留未释放：
- 执行
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME = 'memory/sql/sp_head::main_mem_root';，值 >500MB 就说明有泄漏 - 立刻重启 MySQL ——
sp_head内存无法在线清理，只有重启才能归零；别信“过一阵自己释放” - 后续要长期运行触发器/函数，必须在还原完成后，把
table_open_cache_instances改回合理值（如 8），否则日常查询也会慢
最易被忽略的是：还原用的客户端连接不会自动释放 sp_head 上下文，哪怕你 Ctrl+C 中断，那段内存就卡死在 main_mem_root 里，直到 mysqld 重启。所以只要还原过程出过异常，别犹豫，直接重启。
