根本原因是单条语句或单次传输的数据包超出 max_allowed_packet 限制，MySQL 服务端主动断开连接，并非网络或超时问题。
导入大SQL文件时报 MySQL server has gone away 错误
根本原因通常是单条语句或单次传输的数据包超出了 max_allowed_packet 限制，MySQL 主动断开连接。这不是网络问题，也不是超时，而是服务端直接拒绝接收——哪怕你用 mysql -u root -p 这种看似“简单”的方式也会触发。
怎么改 max_allowed_packet 才真正生效
必须同时修改客户端和服务端两处配置，缺一不可。很多人只改了 my.cnf 里的 [mysqld] 段，却忘了客户端（比如 mysql 命令行工具）也有自己的限制。
-
mysqld配置（服务端）：在/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf的[mysqld]下加一行：max_allowed_packet = 512M（建议设为略大于最大单条 INSERT 的体积） -
mysql客户端配置（命令行导入时用）：在同配置文件的[mysql]段下也加一行：max_allowed_packet = 512M；或者临时指定：mysql --max-allowed-packet=512M -u root -p - 改完必须重启 MySQL：
sudo systemctl restart mysql（Debian/Ubuntu）或sudo systemctl restart mysqld（CentOS/RHEL） - 验证是否生效：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"—— 查看两行输出，mysqld和mysql客户端的值都应是你设的值
光调参数还不够：SQL 脚本本身要适配
即使 max_allowed_packet 调到 1G，如果脚本里全是单条含 50 万行的 INSERT INTO ... VALUES (...),(...),...，依然可能失败。MySQL 解析长 SQL 时内存压力大，且某些版本对单语句长度有隐式上限。
- 用
sed或split-sql类工具把大 INSERT 拆成每 1–5 万行一批，例如：sed -i 's/),(/),\n(/g' big.sql配合换行切分（慎用，需先备份） - 导入前关闭自动提交：
SET autocommit=0;，并在每万行后显式COMMIT;（适用于自己生成的脚本） - 优先用
mysqlimport或LOAD DATA INFILE替代纯 SQL 导入——它们绕过 SQL 解析器，速度快一个数量级，且不受max_allowed_packet约束（但要求文件在服务端磁盘且有 FILE 权限）
导入中途卡住或慢得异常？检查是不是锁表或日志写满
max_allowed_packet 调对了，不代表导入就一定快。大批量写入常被其他机制拖慢：
- 确认没开
innodb_force_recovery，它会让 DML 失效 - 临时关闭唯一键/外键检查：
SET unique_checks=0; SET foreign_key_checks=0;（导入完记得恢复） - 检查
innodb_log_file_size是否太小——大批量 INSERT 会频繁刷 log，若 log 文件总和小于 256MB，容易成为瓶颈；建议设为 512MB 或 1G（需停库重建） - 避免在高峰时段导入；如用
mysqldump生成的脚本，确认没带--single-transaction以外的隔离干扰项
真正卡点往往不在参数本身，而在「你以为改了服务端就完了」——客户端、SQL 结构、InnoDB 日志、甚至磁盘 I/O 调度策略，每个都可能让导入从 2 分钟变成 2 小时。
