Navicat备份时出现“MySQL server has gone away”错误，主因是max_allowed_packet过小（需≥268435456字节）或wait_timeout/interactive_timeout超时（需同步设为28800且一致），须断开并重新连接Navicat才能生效。
Navicat 备份时出现 MySQL server has gone away，基本可以确定不是服务宕了，而是备份过程中触发了 MySQL 的连接中断机制——90% 是 max_allowed_packet 不够大，剩下 10% 是 wait_timeout 或 interactive_timeout 先扛不住了。
Navicat 备份前必须调大的两个参数
Navicat 的“备份数据库”功能本质是执行 mysqldump 逻辑：先查结构、再拼 INSERT、最后打包成 SQL 文件。一旦表里有 BLOB、TEXT 或批量 INSERT 超长，就会撞上 max_allowed_packet 限制；而整个备份过程若耗时较长（比如含百万级数据的单表），又容易被 wait_timeout 主动断连。
-
max_allowed_packet必须 ≥ 256M（即268435456字节），否则导出中途会静默截断，你看到的可能是“备份完成但文件只有几 KB”或“卡在某张表不动” -
wait_timeout和interactive_timeout必须同步设为28800（8 小时）或更高，且值要一致——Navicat 连接属于交互式，但部分 MySQL 8.0+ 版本在备份流程中会降级走wait_timeout - 改完后必须在 Navicat 中**断开当前连接，再重新连接**，否则旧连接仍用老参数
Navicat 里怎么快速生效（不用改配置文件）
如果你没有服务器 root 权限，或只是临时导一次，直接在 Navicat GUI 里改最省事：
- 打开
工具 → 服务器监控 → 选中目标数据库 → 变量页签 - 找到
max_allowed_packet，双击修改为268435456（别写256M，GUI 不认单位后缀） - 找到
wait_timeout和interactive_timeout，都改为28800 - 点“刷新”按钮，然后关闭该窗口 → 在左侧连接列表右键“断开连接” → 再右键“连接”
注意：这个操作只影响当前 Navicat 实例的这次连接，关掉 Navicat 就失效。如果备份中途断开，重连后得再设一遍。
命令行备份更可控，顺便绕过 Navicat 的坑
Navicat 备份界面不暴露 --max-allowed-packet 参数，但你可以手动用命令行跑等效操作，还能加更多安全选项：
- 终端进 MySQL 安装目录 bin 下，执行：
mysqldump --max-allowed-packet=512M -u root -p --single-transaction --routines --triggers db_name > backup.sql -
--single-transaction避免锁表，--routines和--triggers确保存储过程和触发器不丢 - 如果提示权限不足，说明你没 SUPER 权限，那就别用
--single-transaction，改用--lock-tables=false（但可能数据不一致） - 导出大库时建议加
--skip-extended-insert，把每行 INSERT 拆成独立语句，降低单包体积，也方便后续排查哪一行出错
云数据库（如阿里云 RDS）的特殊处理
云厂商通常禁用 SET GLOBAL，Navicat 的变量页和命令行 SET 都会报 Access denied。这时只能走参数模板：
- 进云控制台 → 找到对应 RDS 实例 → 参数设置 → 编辑参数模板
- 搜索并修改：
max_allowed_packet = 512M、wait_timeout = 28800、interactive_timeout = 28800 - 保存模板 → 应用到实例 → **重启实例才生效**（注意业务影响）
- 重启后，在 Navicat 里务必重新连接，别复用旧连接
真正容易被忽略的是：Navicat 自己也有一个客户端级的 max_allowed_packet，它不读服务端值。所以哪怕你把 MySQL 服务端设到 1G，Navicat 还是按默认 4MB 收包——这也是为什么有时“明明改了配置却还报错”的根本原因。
