MySQL分卷导出内存爆掉应调参并表级拆分：加--skip-extended-insert、--single-transaction，设--net_buffer_length=64K和--max_allowed_packet=256M，优先按表导出而非库级。
mysqldump 分卷导出时内存爆掉怎么办
直接用 mysqldump 导出几十 gb 的库，不加控制大概率卡死或 oom。根本原因是默认把整个表内容读进内存再写入管道，中间没缓冲节流。
实操建议：
- 加 --skip-extended-insert 减少单行长度，避免解析器吃太多内存
- 必须配 --single-transaction（InnoDB）或 --lock-tables=false（MyISAM），否则锁表时间不可控
- 用 --net_buffer_length=64K 和 --max_allowed_packet=256M 控制网络包大小，防连接中断
- 表级拆分比库级更稳：对大表单独 dump，小表合并，避免单文件过大
split + zip 分卷压缩后解压报错“invalid zip file”
常见现象是用 split -b 1G dump.sql dump_part_ 切完，再对每个 part 跑 zip，结果 zip 文件无法识别——因为 split 按字节切，可能把一行 SQL 或一个 UTF-8 字符截断在两个文件里，zip 头部损坏。
正确做法：
- 先用 mysqldump 每张表输出独立文件：mysqldump --databases db_name --tables t1 t2 t3 > db_dump.sql，再配合 --tab 输出为纯文本（适合后续切分）
- 若必须分卷，用 split -l 10000（按行切），并确保每行以 ; 结尾（mysqldump --skip-extended-insert 可帮上忙）
- zip 分卷请用 zip -s 1g dump.sql.zip，不是对 split 后的文件分别 zip；-s 是 zip 原生分卷，支持跨卷校验和恢复
Windows 下用 7-Zip 命令行分卷压缩 MySQL 导出文件
PowerShell 或 cmd 中直接调 7z 比 GUI 稳定，尤其处理超大文件时不会假死。
关键命令与参数：
- 7z a -v1g -tzip dump_full.7z dump.sql：生成 1GB 每卷的 ZIP 分卷（注意后缀必须是 .7z，即使格式是 ZIP）
- -v1g 是分卷大小，不能写成 -v1024m，7-Zip 对单位敏感
- 不要用 -r 递归，单文件就别加
- 解压时只需 7z x dump_full.7z.001，它会自动找齐所有卷
导出后校验分卷完整性但找不到 checksum 工具
分卷 ZIP 或 split 文件一旦某卷损坏，还原时可能静默失败（比如只报“SQL syntax error near ...”），实际是前面几 MB 数据错位了。
轻量校验方案：
- 对原始 dump.sql 运行 sha256sum dump.sql（Linux/macOS）或 certutil -hashfile dump.sql SHA256（Windows）存底
- 分卷压缩后，用 unzip -t 测试 ZIP 分卷：unzip -t dump.sql.zip.001（注意指定 .001 卷即可）
- 如果用了 split + 单独 zip，必须对每个 zip 文件单独 unzip -t，且还原前先 cat dump_part_* | sha256sum 对比回原始 hash
最容易被忽略的是：MySQL 导出文件末尾是否含换行符。有些脚本自动 trim，导致拼接后最后一行 SQL 缺 ;，导入时报错却查不到源头。导出后用 tail -c1 dump.sql | od -c 确认结尾是 \n。
