“MySQL server has gone away”是连接超时而非数据库崩溃，根因是锁表、I/O延迟及Navicat默认30秒Socket Timeout过短；需调高Socket Timeout、启用Keep alive、禁用Preview DDL、拆分复杂ALTER操作，并警惕SSH隧道与NAT导致的心跳失效。

修改大表结构时提示“MySQL server has gone away”

这不是数据库崩了，而是连接在 alter table 执行中途被主动切断。navicat 默认 30 秒超时，但百万行加索引、改字段类型等操作常需数分钟——超时只是表象，锁表和 i/o 延迟才是根因。

• Socket Timeout（客户端读取超时）必须调高：右键连接 → Edit Connection → Advanced → Socket Timeout(sec) 改为 300 或 1800
• 勾选 Keep connection alive，间隔设为 60；超过 300 秒部分 NAT 设备会丢心跳
• 仅改服务端 wait_timeout 不够：Navicat 新建连接不继承全局值，得在 Advanced → SQL Query 框里填 SET SESSION wait_timeout = 28800; 立即生效

Navicat 可视化改结构时界面卡死不动

界面长时间显示“正在执行…”却无进展，大概率是降级用了 COPY 算法（比如改主键或唯一索引），全程锁表 + 全量复制数据。此时网络没断，但 Navicat 等不到响应，最终触发自身超时。

• 关闭 Preview DDL before execution（Preferences → DDL）：否则会先跑 SELECT COUNT(*)，极易被元数据锁阻塞
• 避免单条语句干多件事：Navicat 把“改类型+加索引+改注释”拼成一条 ALTER TABLE，内存压力大，可能撞上 max_allowed_packet
• 主键/唯一索引变更务必手动拆分：先 ADD COLUMN，再 UPDATE 填值，最后 DROP PRIMARY KEY + ADD CONSTRAINT，用命令行执行更可控

用了 SSH 隧道或云 NAT，心跳全失效

一旦勾选“使用 SSH 隧道”，Navicat 和 MySQL 的超时设置全部作废——控制权移交 SSH 协议栈。阿里云、腾讯云 NAT 网关默认 300–900 秒空闲超时，你改不了，只能靠更密心跳兜底。

navicatmysql

Navicat For MySQL

下载

• Navicat SSH 配置页必须启用 Keep alive，间隔设为 15 或 30
• 跳板机或目标服务器的 /etc/ssh/sshd_config 需含：ClientAliveInterval 30 和 ClientAliveCountMax 3，改完 sudo systemctl restart sshd
• 云环境别信“设成 300 就够”，NAT 实际行为常比文档宽松，心跳间隔 ≤ 60 更稳妥

同步或导出中断后不会续传

Navicat 的结构同步、数据导出任务一旦断连，就整个重来——它不记录已处理行数，也不支持断点续传。这是最隐蔽也最浪费时间的坑。

• 确认连接编辑页 Advanced 中已取消勾选 Disconnect when idle（不同版本叫法略有差异，位置可能在常规页底部）
• 即使服务端 wait_timeout 调到 86400，Navicat 自身仍可能提前发 COM_QUIT，这个选项漏掉就白调
• 对千万级表，优先考虑 mysqldump + --skip-extended-insert 或 pt-online-schema-change，Navicat 可视化不是万能解

真正卡住的地方从来不在网络设置里，而在 ALTER TABLE 是否触发全表拷贝、是否被元数据锁堵住、以及你有没有意识到 Navicat 的“自动重连”其实是“自动重头再来”。