error 2006根本原因是mysql服务端主动断开连接，需同步调大max_allowed_packet、wait_timeout和interactive_timeout三个参数，并确保服务端与客户端配置均生效。
直接结论：这不是MySQL挂了，是连接被主动切断——必须同步调大 max_allowed_packet、wait_timeout 和 interactive_timeout 三个参数，且服务端和客户端两边都要覆盖。
为什么导入中途报 ERROR 2006 (HY000): MySQL server has gone away
错误日志里出现 MySQL server has gone away，不代表服务崩溃或网络断开，而是 MySQL 主动终止了当前连接。常见触发场景包括：
- 单条
INSERT INTO ... VALUES (),(),()...含上万行数据，包体积超过max_allowed_packet限制（默认仅 4MB） - 导入耗时太久，空闲时间超过
wait_timeout（非交互式）或interactive_timeout（命令行交互式） - SQL 文件开头带 UTF-8 BOM 字节，导致首行解析失败，后续语句错位，间接引发超时或包解析异常
- 用 phpMyAdmin 或 Navicat 直接拖入大文件，它们自身有上传缓冲限制，且不暴露底层参数，出错难定位
mysql 命令行导入时仍报 ERROR 1153: Got a packet bigger than 'max_allowed_packet' bytes
这个错误来自客户端，说明你只调了服务端的 max_allowed_packet，但本地 mysql 工具仍按默认值收包。必须显式传参：
- 导入命令加
--max-allowed-packet=512M，例如：mysql --max-allowed-packet=512M -u root -p database_name - 如果含 emoji 或四字节字符，顺手加上
--default-character-set=utf8mb4，避免乱码干扰 SQL 解析 - 别依赖
SET GLOBAL max_allowed_packet = ...后就直接导入——该设置只影响新连接，而当前命令行进程已启动，不受影响 - 检查当前客户端实际生效值：
mysql --help | grep "max-allowed-packet"
临时调参后仍中断？确认 timeout 是否真正生效
wait_timeout 和 interactive_timeout 必须成对设，且注意作用对象：
- 用
mysql命令行导入属于交互式连接，优先看interactive_timeout；但若导入脚本里用了source或管道重定向，可能走非交互路径，此时wait_timeout才起作用 - 执行
SET GLOBAL wait_timeout = 86400;后，必须退出当前 mysql 客户端、重新登录，新会话才会继承该值 - 验证是否生效：
SELECT @@session.wait_timeout, @@session.interactive_timeout;—— 看的是当前会话值，不是全局值 - 云数据库（如阿里云 RDS）可能限制
SET GLOBAL权限，此时只能走配置文件 + 重启方式
拆分大 SQL 文件时最常踩的坑
别用 split -l 10000 dump.sql 这种按行硬切的方式，极易破坏语法结构：
-
CREATE TABLE和后续INSERT被切到不同文件，第二段执行失败 - 多值
INSERT INTO t VALUES (1),(2),(3),...,(10000)被截断在中间，变成非法 SQL - 事务块（
BEGIN; ... COMMIT;）被切开，导致部分写入、部分回滚不可控 - 推荐做法：用
mysqldump --skip-extended-insert重导出，让每条INSERT只插一行，再配合sed或专用工具（如pt-fingerprint）按语句边界切分
真正麻烦的不是参数数字填多少，而是哪边改了、哪边没改、改完有没有生效、生效的是不是当前连接——所有环节都得验，漏一个就白调。
