Navicat导入SQL报“server has gone away”根本原因是MySQL服务端主动断连，受@@wait_timeout控制；解决需设Keepalive间隔为该值的1/3～1/2、禁用多语句执行、调大max_allowed_packet、加SET autocommit=1，并避免GUI加载超大文件。
Navicat导入SQL时提示“server has gone away”或“Lost connection”
根本不是网络抖动，而是mysql服务端主动kill了空闲连接。navicat执行sql文件时走的是非交互式连接路径，受@@wait_timeout控制（不是@@interactive_timeout），一旦脚本执行时间超过该值，且中间没心跳，连接就被回收。
常见现象包括：卡在某条INSERT后不动、报错MySQL server has gone away、或静默断开只剩灰色连接状态。
- 立刻查当前生效值：
SELECT @@wait_timeout, @@interactive_timeout;—— 注意看第一个值 - 云数据库（如阿里云RDS）通常把
wait_timeout锁死在300～600秒，你改Navicat设置前必须先确认这个底限 - Navicat的“保持连接间隔”必须设为
wait_timeout的1/3～1/2（比如服务端是300，就填240；是60，就填≤45） - 输错单位是高频坑：填
60000以为是60秒，其实是60秒×1000=60000毫秒=60秒？不对——Navicat这里单位就是秒，填60000等于每16.7小时才发一次心跳，必断
执行SQL文件时中途断开，但keepalive已开启
说明问题不在空闲超时，而在脚本解析或执行层。Navicat对大SQL文件的默认处理方式容易触发隐性失败。
- 取消勾选
在每个运行中运行多个查询：否则Navicat会尝试用分号切分语句，遇到存储过程里的DELIMITER ;;或函数体内的分号就崩溃，不报错只断连 - 确认
max_allowed_packet足够大：导入含超长INSERT的脚本时，若服务端该值太小（默认4M），会直接报Packets larger than max_allowed_packet are not allowed并终止，建议设为100M - 脚本开头加
SET autocommit = 1;：避免Navicat因事务未提交卡住；如果要用事务，务必在脚本末尾显式写COMMIT;或ROLLBACK;
Navicat“运行SQL文件”功能卡死或内存爆掉
GUI模式加载大文件（尤其>200MB）会把整个文件读进内存做语法预检，极易OOM或假死。这不是连接问题，是客户端资源耗尽。
- 关闭
执行前验证SQL语法：跳过客户端解析，让MySQL服务端自己报错 - 选择
快速执行(不返回结果集)：避免Navicat逐行收结果、攒缓冲区 - 拆文件：用文本工具把
CREATE TABLE和INSERT分开，先跑结构再跑数据；后者可启用忽略错误继续执行防单条失败中断全量 - 终极方案：别用Navicat导入，改用命令行
mysql -h host -u user -p database ，它不占GUI内存，也不做语法校验，纯管道流式执行
云数据库环境下的特殊限制
阿里云RDS、腾讯云CDB等平台通常禁改wait_timeout，且中间有代理层（如SLB、NAT网关），TCP keep-alive可能被截断。仅调Navicat心跳不够。
- 必须同时勾选
使用keep alive（TCP层保活）和设置保持连接间隔（应用层心跳）——这是两套机制，缺一不可 - 自动重连要打开：
连接属性 → 高级 → Reconnect when connection is lost，它比心跳更可靠，能在断连后自动重建会话 - 如果脚本含
LOCK TABLES或长时间事务，wait_timeout不生效，但连接会被占用直至超时；这类脚本必须人工确保UNLOCK TABLES或COMMIT存在，否则Navicat认为“还在干活”，不会发心跳
wait_timeout和interactive_timeout的区别——执行SQL文件走的是前者，而你查变量时可能只看了后者，误判超时阈值。 
