根本原因是MySQL服务端主动切断空闲连接，需同步调大wait_timeout、interactive_timeout（均设为86400）、net_read_timeout与net_write_timeout（均设为600），并使用“运行SQL文件”功能配合“继续执行遇到错误的语句”及兼容模式设置。
还原大SQL文件时连接中断，根本不是网络问题
navicat「运行 sql 文件」中途断连，90%以上情况和网络无关，而是服务端主动切断了空闲连接。mysql 默认 wait_timeout 是 28800 秒（8 小时），但很多云数据库或高负载环境会设成 300 秒甚至更短——而一个含百万行数据的 insert 可能卡在某条语句上超过这个阈值，连接就被干掉。
必须改服务端的四个超时参数
只调 Navicat 客户端没用，关键得让 MySQL 服务允许长连接持续存在：
-
wait_timeout和interactive_timeout都要设为 86400（24 小时），否则还原中途空闲几秒就断 -
net_read_timeout设为 600，防大数据块读取超时（比如 BLOB 字段） -
net_write_timeout同样设为 600，避免 INSERT 大批数据时写入慢触发中断 - 改完后执行
set global命令即可生效，无需重启（但要注意权限：需 SUPER 或 SYSTEM_VARIABLES_ADMIN）
Navicat 里别用“粘贴执行”，必须用“运行 SQL 文件”
把整个 SQL 文件复制进查询窗口点执行，是失败率最高的操作方式：
- 客户端逐行解析+发送，中间任何一行出错或超时，后续全丢
- 字符编码错乱、BOM 头、注释格式不兼容都可能导致某行卡死
- Navicat 缓冲区有上限，超大文件直接截断，报错行号完全对不上
- 正确做法：右键目标库 →「运行 SQL 文件」→ 勾选「继续执行遇到错误的语句」→ 在「执行前运行自定义命令」框里填
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';
跨版本还原时，中断常由语法不兼容引发
表面报“连接中断”，实际是 SQL 执行失败后连接被释放。典型诱因：
- MySQL 8.0 备份往 5.7 还原，遇到
utf8mb4_0900_ai_ci排序规则直接报错退出 -
DEFAULT CURRENT_TIMESTAMP在 5.6 及更早版本不支持，必须删掉或替换为具体时间字面量 - SQL Server 高版本导出的
STRING_AGG函数，在低版本里无法识别，整条语句失败 - Navicat 导出时务必勾选「兼容模式」并指定目标版本，否则默认按当前服务器版本生成语法
最容易被忽略的是：中断未必发生在最后一行，可能卡在第 3 万行某个触发器定义里——所以别只看报错位置，得先确认语法是否真的向下兼容。
