根本原因是长事务、元数据锁与空闲超时叠加导致连接中断；须同步调整Navicat的Socket Timeout（设300+秒）、Keep-alive间隔（设60秒）和MySQL端wait_timeout（SET SESSION wait_timeout=28800）。
Navicat 可视化修改表结构时卡住或报错 MySQL server has gone away
根本原因不是“操作太慢”，而是修改过程（如添加索引、重命名字段）触发了长事务 + 大量元数据锁 + 长时间无网络交互，导致连接被中间设备或 mysql 服务端主动断开。此时 navicat 的默认超时设置（通常为 30 秒）远不够用。
必须改的三个超时参数：Socket Timeout、Keep-alive 间隔、MySQL wait_timeout
这三个参数缺一不可，且作用层级不同：
-
Socket Timeout是 Navicat 客户端层面的读取超时，控制“执行 ALTER TABLE 后等结果返回的最大等待时间”。右键连接 → Edit Connection → Advanced → 找到Socket Timeout(sec)，建议设为300（5 分钟）起步；若表有千万级数据，可设为1800（30 分钟） -
Keep-alive ping interval是保活心跳间隔，防止 NAT/防火墙静默断连。路径同上，在 Advanced 页勾选Keep connection alive，值设为60（不能大于 300，否则可能失效） -
wait_timeout是 MySQL 服务端空闲连接存活时间。仅调客户端没用——如果服务端 300 秒就 kill 掉空闲连接，客户端再怎么 ping 也救不回来。需在连接建立后立即执行：SET SESSION wait_timeout = 28800;（放入 Advanced → SQL Query 框中）
ALTER TABLE 过程中真正耗时的环节和对应规避方式
可视化修改表结构（比如加字段、改类型）背后实际执行的是 ALTER TABLE ... ALGORITHM=INPLACE 或全表拷贝，耗时点不在网络，而在磁盘 I/O 和锁等待。超时只是表象，卡住才是真问题：
- 若表行数 > 100 万，Navicat 默认的“预览变更”会尝试
SELECT COUNT(*)，这个查询本身就会被锁阻塞。解决办法：关闭预览（Preferences → DDL → uncheck “Preview DDL before execution”） - 修改主键或唯一索引字段时，MySQL 可能降级为
COPY算法，全程锁表。此时哪怕 socket 不超时，Navicat 界面也会显示“正在执行…”不动。应改用命令行分步操作，或在低峰期执行 - Navicat 的“保存修改”按钮本质是拼接并执行完整 DDL，不会自动拆解。例如同时改字段类型 + 加索引 + 改注释，它会合成一条语句。而 MySQL 对单条 DDL 的内存消耗更大，易触发
max_allowed_packet限制，报错MySQL server has gone away。建议手动拆成多条独立语句执行
容易被忽略的驱动与认证插件兼容性问题
MySQL 8.0+ 默认使用 caching_sha2_password 插件，但旧版 Navicat（
- 检查方法：执行
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_user';，确认plugin值不是caching_sha2_password - 临时绕过：用命令行执行
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; FLUSH PRIVILEGES; - 长期方案：升级 Navicat 至 16.1.14 或更高版本，并确认 Advanced → Driver 中显示的是
mysql-connector-j-8.0.33或更新版本
真正卡住的时候，别只盯着“超时数字”调大，先看 SHOW PROCESSLIST 里那个 ALTER 是否还在 State = altering table —— 如果是，说明服务端没挂，只是客户端等不及了；如果不是，那问题已经下沉到磁盘或锁层面，调超时毫无意义。
