navicat 16可视化改表结构报“mysql server has gone away”或卡住的根本原因是socket timeout、keep-alive和wait_timeout三参数未同步调整：需在连接高级设置中将socket timeout设为300秒以上、启用keep connection alive并设间隔60秒，同时在sql query框中添加set session wait_timeout = 28800确保会话级生效。
Navicat 16 可视化改表结构报 “MySQL server has gone away” 或卡在 “正在执行…”，根本不是网络慢，而是 Socket Timeout、keep-alive 和 wait_timeout 三个参数没同步调，缺一不可。
Socket Timeout 设太低导致客户端主动断连
Navicat 默认 Socket Timeout 是 30 秒，但 ALTER TABLE 加索引或改字段类型时，MySQL 后台可能要花几分钟做 I/O 或等 MDL 锁 —— 客户端等不及就自己断了，报错 MySQL server has gone away，而服务端 DDL 其实还在跑。
- 右键连接 → Edit Connection → Advanced → 找到
Socket Timeout(sec)，设为300（5 分钟）起步；千万级表建议1800（30 分钟） - 这个值只控制“发完 ALTER 后等返回结果的最大时间”，不控制 MySQL 内部执行耗时
- 设太高也没用：超过中间 NAT/防火墙的静默超时（通常 5–15 分钟），照样断
Keep-alive 心跳没开或间隔过大
Socket Timeout 调高只是治标；如果连接中途被防火墙或云厂商 LB 静默回收（因长时间无数据包），再长的超时也白搭。Navicat 的 keep-alive 是唯一能维持链路活跃的机制。
- 同在 Advanced 页，勾选
Keep connection alive，填入60（单位秒） - 不能设 >
300：部分 NAT 设备会丢掉间隔过长的心跳包，反而失效 - 它只在连接空闲时发 ping，不影响正在执行的 DDL，也不增加服务器压力
MySQL 端 wait_timeout 没改，客户端保活也白费
就算 Navicat 一直发心跳，如果 MySQL 服务端自己把空闲连接 kill 了（默认 wait_timeout=28800 即 8 小时，但很多云数据库设成 300 秒），那心跳再勤也没用。
- 在同一个 Advanced 页的
SQL Query框中，填入：SET SESSION wait_timeout = 28800; - 必须用
SESSION级别：用GLOBAL对 Navicat 新建连接无效，它不继承全局设置 - 该语句会在每次连接建立后自动执行一次，确保生效
- 查当前值可运行：
SELECT @@session.wait_timeout;
为什么调完三个参数还卡住？重点盯这几个点
超时参数只是让连接不断，但卡住的真正原因常是锁、算法降级或 SQL 合并问题，这些不会报超时，但会让界面一直显示“正在执行…”。
- 关闭预览：
Preferences → DDL → uncheck “Preview DDL before execution”，否则 Navicat 会先跑SELECT COUNT(*)，极易被未提交事务阻塞 - 别一次改太多：同时改字段类型 + 加索引 + 改注释，Navicat 会合成一条大 DDL，易触发
max_allowed_packet或内存不足 - 主键/唯一索引变更、TEXT 字段改类型，默认走 COPY 算法，全程锁表 —— 这类操作直接放弃可视化，手写
ALTER TABLE ... ALGORITHM=INPLACE或分步执行 - 点保存前一定拉到底看右下角灰字预估 SQL，确认是
MODIFY COLUMN（安全）还是CHANGE COLUMN（重建字段，危险）
