Navicat 16保存表结构修改卡在“正在执行…”是因合并DDL触发MySQL元数据锁与内存瓶颈，需关闭预览、拆分操作、调高Socket Timeout及wait_timeout，并规避COPY算法。
Navicat 16保存表结构修改卡在“正在执行…”不动
这不是网络延迟或mysql慢，而是navicat把多个ddl操作合并成一条语句执行，触发了mysql的内存与锁机制瓶颈。比如同时改字段类型 + 加索引 + 更新注释，它会拼成单条alter table，而mysql对这种复合ddl需更多解析内存和元数据锁等待时间。
常见现象包括：界面长时间显示“正在执行…”，SHOW PROCESSLIST里看到状态是Waiting for table metadata lock，或直接报错MySQL server has gone away（服务端因超时主动断连）。
- 关闭Navicat的「预览变更」功能：Preferences → DDL → 取消勾选
Preview DDL before execution，避免它偷偷执行SELECT COUNT(*)这类阻塞查询 - 手动拆分操作：不要一次点“保存修改”，而是分步执行——先改字段，等完成再加索引，最后更新注释
- 确保
wait_timeout已调高：在连接的Advanced → SQL Query中填入SET SESSION wait_timeout = 28800;，否则服务端300秒就kill空闲连接
Socket Timeout设太小导致“MySQL server has gone away”
Navicat默认Socket Timeout是30秒，但一个千万行表加索引可能耗时数分钟。超时后客户端断开，服务端仍在后台运行，造成“假死”错觉。
这个参数和MySQL的wait_timeout、interactive_timeout不是一回事：前者是Navicat等结果返回的等待上限，后者是服务端空闲连接存活时间。只调服务端参数没用，客户端也必须同步改。
- 右键连接 → Edit Connection → Advanced → 找到
Socket Timeout(sec)，设为300起步；若表超500万行，建议1800 - 勾选
Keep connection alive，间隔设为60（不能大于300，否则部分NAT设备不认） - 别依赖“自动重连”——重连后原ALTER还在跑，新连接看不到进度，只会更混乱
“保存修改”按钮背后实际执行的是ALGORITHM=COPY？
Navicat不显示底层算法，但当你修改主键、唯一索引字段，或从VARCHAR(255)扩到VARCHAR(1000)时，MySQL可能降级为COPY算法，全程锁表+全量拷贝。此时哪怕Socket没超时，Navicat界面也会卡住不动，因为没收到任何反馈包。
这种操作无法靠调参提速，只能规避：
- 用命令行确认当前操作是否走
INPLACE：SHOW CREATE TABLE your_table\G后手动构造ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE测试 - 大表结构变更务必避开高峰期，并提前在从库验证
- 如果必须用Navicat，至少关掉
Auto-commit（Connection → Advanced → uncheckAuto-commit），避免每次DDL都触发额外事务开销
为什么改完字段类型后Navicat要花几十秒才刷新表结构？
不是数据库响应慢，而是Navicat在本地重建元数据缓存。它会重新拉取information_schema.COLUMNS、STATISTICS、KEY_COLUMN_USAGE等十几张系统表，再做本地渲染。表越多、字段越复杂（比如含JSON或Generated Column），这步越慢。
这个过程完全在客户端发生，和MySQL无关，也绕不过去，但可以缓解：
- 编辑前先断开其他无关数据库连接，减少Navicat后台元数据同步压力
- 禁用「自动完成」和「语法高亮」（Tools → Options → Editor）——它们会让缓存重建多花2–3倍时间
- 别在「表设计视图」里反复切tab，每次切换都会触发一次完整元数据重载
information_schema直到确认变更生效，这个轮询周期默认是5秒一次，且不可配置。如果你刚执行完ALTER，立刻点开表数据，它可能还在第3次轮询中——你以为卡了，其实只是等得不够久。
