必须同时调大MySQL服务端和Navicat客户端的max_allowed_packet值，因Navicat默认使用旧协议或较低上限（如16MB）发送语句，即使服务端设为500M，若客户端未同步配置，大SQL仍被截断导致连接丢失。
直接改 max_allowed_packet 能解决大部分因导入大 sql 文件导致的 “lost connection to mysql server during query” 错误，但必须同时调大客户端和服务端两处配置，否则无效。
为什么只改 my.ini 里的 max_allowed_packet 还是报错
Navicat 导入时，SQL 文件被拆成单条语句（比如一个含 10 万行数据的 INSERT INTO ... VALUES (...),(...),...），如果整条语句体积超过服务端限制，MySQL 就会断开连接——但很多人只改了服务端配置，忘了 Navicat 自身也有默认接收上限。
- 服务端限制由
max_allowed_packet控制（单位字节），默认通常只有 4MB - Navicat 客户端在连接时也会协商这个值，若未显式设置，它可能按旧协议或默认值（如 16MB）发起请求，仍低于你实际要传的语句大小
- 即使服务端设为 500M，若 Navicat 发送的包被本地驱动截断，错误照样出现
怎么正确设置 max_allowed_packet（服务端 + 客户端）
服务端配置生效后，必须让 Navicat 显式使用更大的包限制，否则它不会自动适配新值。
- 编辑 MySQL 配置文件（
my.ini或my.cnf），在[mysqld]节下添加：max_allowed_packet = 512M
- 重启 MySQL 服务（Windows 用服务管理器，Linux 用
sudo systemctl restart mysql） - 在 Navicat 中：右键连接 →「编辑连接」→「高级」选项卡 → 勾选「使用自定义 max_allowed_packet」→ 输入数值（单位 MB，例如
512） - 不要填带单位的字符串（如
512M），Navicat 这里只认纯数字，单位固定为 MB
其他容易被忽略的配套参数
max_allowed_packet 不是孤立参数，它和超时类配置协同起作用。光调大它，但 net_read_timeout 还是 30 秒，大包传输中途也可能被掐断。
- 在同一个
[mysqld]区块里建议一并调整：max_allowed_packet = 512M<br>net_read_timeout = 300<br>net_write_timeout = 300
-
net_read_timeout控制服务器读取客户端数据的最长等待时间，导入大文件时必须同步拉长 - 避免只调
wait_timeout：那是空闲超时，对正在传输的大查询没用 - 改完记得验证：登录 MySQL 执行
SHOW VARIABLES LIKE 'max_allowed_packet';，确认返回值是预期字节数（比如 512M → 536870912）
导入前最后检查项
即使参数全调对了，Navicat 导入界面本身的设置也会影响结果。
- 导入时选择「运行每个语句单独执行」（即不勾选「全部语句作为一个事务」）：避免单个事务过大触发锁或内存溢出
- 禁用「自动提交」反而更危险——大导入中一旦失败，回滚本身就会卡死连接
- 如果 SQL 文件里有
SET NAMES utf8mb4或CREATE DATABASE等前置语句，确保它们不被 Navicat 当作普通数据行误处理（可先用文本编辑器确认文件头无 BOM、无非法字符） - 实在不行，把大 SQL 拆成多个 50MB 以内的文件分批导入，比硬扛更稳
真正麻烦的不是改哪个参数，而是所有环节都得对齐：服务端能收、客户端敢发、网络不截断、超时不触发。漏掉任意一环，错误就还在那儿等着你重试。
