应分批导入并控制事务大小：用sed提取insert语句，split按8000行切分，为每批添加start transaction和commit，再逐个执行mysql -u root -p db_name
直接结论：MySQL导入大SQL文件爆内存，不是SQL写得不对，而是客户端或服务端一次性加载/执行太多——必须分批次切开，同时控制事务大小。
为什么source或mysql -e导入大SQL会OOM
MySQL客户端（如mysql命令行工具）默认把整个SQL文件读进内存再解析执行；遇到含百万级INSERT的单条语句（比如
INSERT INTO t VALUES (...),(...),...带10万行），客户端进程自身先吃光几百MB内存。服务端虽不直接OOM，但大事务会锁表、撑爆innodb_log_file_size和innodb_buffer_pool_size缓冲区，触发系统级OOM Killer。
- 现象：导入中途断连、
ERROR 2013 (HY000): Lost connection to MySQL server during query，dmesg里有Kill process mysqld- 不是
max_allowed_packet不够（那报的是Packets larger than max_allowed_packet）- 也不是
innodb_buffer_pool_size设小了——它影响的是查询缓存，不是导入时的临时解析内存用sed + split分批执行SQL文件（Linux/macOS）
核心是把一个巨型
dump.sql按INSERT语句拆成多个小文件，每份控制在5000–10000行内，再逐个导入。
- 先提取所有INSERT语句：
sed -n '/^INSERT INTO/p' dump.sql > inserts.sql- 按每8000行切分：
split -l 8000 -a 3 - inserts.sql batch_→ 生成batch_aaa、batch_aab等- 给每个分片加上事务头尾（避免每条INSERT单独提交）：
for f in batch_*; do echo "START TRANSACTION;" | cat - "$f" | echo "COMMIT;" >> "$f".sql; done- 逐个导入：
for f in batch_*.sql; do mysql -u root -p db_name注意：
split只按行切，不保证INSERT语句完整性；若原SQL含多行VALUES，需先用mysqldump --skip-extended-insert导出，确保每行一个INSERT。用mysql命令行参数控制批量行为
不改SQL文件，靠客户端参数压制内存占用：
- 禁用自动提交：
mysql -u root -p --init-command="SET autocommit=0" db_name ，配合SQL里显式<code>COMMIT可减少日志压力- 限制单次读取大小（仅对mysql 8.0+有效）：
mysql --max-allowed-packet=64M --net-buffer-length=1M -u root -p db_name ，<code>--net-buffer-length控制客户端网络包缓冲，能缓解解析阶段内存堆积- 绝对不要加
--force——它会让客户端忽略错误继续执行，OOM前可能已写入脏数据这些参数治标不治本；如果
dump.sql本身含CREATE TABLE和INSERT混排，仍建议先用mysqldump --no-create-info分离结构与数据，再分批导入数据部分。导入前必须做的三件事
否则分批也救不了：
- 确认
max_allowed_packet≥ 单条最长INSERT的字节数（查SELECT @@max_allowed_packet，单位字节；设为256M即268435456）- 临时调大
innodb_log_file_size（需停库重置），避免大事务刷日志失败；线上环境慎动，优先选小事务- 关掉
innodb_doublewrite（仅测试环境！）：SET GLOBAL innodb_doublewrite = OFF;，能提速30%，但牺牲崩溃恢复安全性最易被忽略的是事务粒度——哪怕分了100批，如果每批仍是
INSERT ... VALUES (1),(2),...,(10000)一条语句，客户端内存照样崩。真正安全的做法：每批只含100–500行INSERT，且每条INSERT独立成行。
如何解决MySQL导入SQL导致的内存溢出_分批次执行SQL或减小事务规模
落萱吖_2536
2026-05-14
889人浏览
原创
