“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 秒空闲超时，你改不了，只能靠更密心跳兜底。
- 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 可视化不是万能解
