ERROR 2006不是MySQL崩溃，而是服务端主动断连；主因是max_allowed_packet过小导致数据包被拒，或wait_timeout/interactive_timeout过短引发空闲连接超时关闭，需同步调大服务端与客户端参数并重启生效。
2006 错误不是 MySQL 崩了，是它主动把你踢下线了。根本原因就两个：单次传输数据太大，或连接空闲太久——服务端觉得“你没动静，我先撤了”，然后你再发请求，就收到 ERROR 2006 (HY000): MySQL server has gone away。
max_allowed_packet 太小，INSERT 一长串值直接被截断
MySQL 默认 max_allowed_packet 只有 4MB（8.0.22 是 64MB，但大 SQL 文件仍常超限）。比如用 mysqldump 导出的带多值 INSERT INTO t VALUES (),(),()...; 语句，一条就可能几百 MB，远超限制。
- 服务端收到超长包，直接断连，不报语法错，只丢
2006 -
mysql命令行客户端也受该参数约束：改了my.cnf不等于客户端生效，必须显式加--max_allowed_packet=512M - Navicat/DBeaver 等 GUI 工具通常不暴露该参数，只能靠服务端调大 + 重启连接
- 如果 SQL 含 emoji 或四字节 UTF-8，还要同步加
--default-character-set=utf8mb4，否则解析卡死也可能伪装成 2006
wait_timeout / interactive_timeout 设置过短
这两个值控制连接空闲多久后被服务端关闭：wait_timeout 针对非交互连接（如应用连接池），interactive_timeout 针对交互式连接（如命令行、Navicat）。默认都是 28800 秒（8 小时），但导入大 SQL 时，单条语句执行就可能耗时几十分钟甚至更久。
- 哪怕只有一条 INSERT 耗时超过
wait_timeout，执行中途也会被断开，报 2006 - PHP 应用里用 mysqli 扩展，即使服务端改了，PHP 进程不重启（如 PHP-FPM），
mysqli仍用旧缓存值通信 - 检查是否生效不能只看
show variables，还得确认客户端实际协商值：运行mysql -u root -e "SELECT @@session.max_allowed_packet, @@session.wait_timeout;"
SQL 文件本身带 BOM 或格式陷阱
UTF-8 编码的 SQL 文件若含 BOM（），phpMyAdmin 或某些 CLI 工具会把首行解析成非法命令，后续语句全乱套，最终也退化为 2006；而 Navicat 可能静默跳过，但插入数据错位。
- 用
file -i dump.sql检查编码，用vim或iconv -f utf-8 -t utf-8 -c dump.sql > clean.sql去 BOM - 不要用
split -l 1000硬切 SQL 文件：CREATE TABLE 和 INSERT 可能被劈开，多值 INSERT 被截断，事务边界丢失 - 真要拆分，优先用
mysqldump --skip-extended-insert重导，让每条 INSERT 只插一行，再按行安全切分
最易被忽略的是：改完 my.cnf 必须重启 mysqld，且所有依赖它的进程（PHP-FPM、应用服务、GUI 客户端）都得重新建连——参数不会热加载到已有连接中。
