Navicat 15修改大表结构卡在“保存”本质是同步执行ALTER TABLE导致GUI阻塞，MySQL需全表重建或锁表，而Navicat不校验外键、超时参数及算法类型，易因锁等待、日志不足或外键约束失败；应改用pt-online-schema-change等在线工具。
Navicat 15 修改大表结构卡在“保存”按钮上
本质不是 navicat 崩溃或 bug，而是它把 alter table 操作直译为单条同步 sql，在 mysql 执行期间全程阻塞、等待响应。当表行数超百万、字段含 blob 或有外键时，mysql 内部要重建表（即使启用了 algorithm=inplace），navicat 的 gui 线程就卡死在“等待服务器返回 ok”这一步。
常见现象包括：ALTER TABLE 提交后界面无反应、进度条不动、CPU 占用低但磁盘 I/O 持续 100%、几小时后报 Lock wait timeout exceeded 或直接断连。
- 别点“重试”或反复保存——每次都会触发新一轮全表拷贝
- 检查是否启用了
innodb_file_per_table=ON：若该表 .ibd 文件已超 10GB，Navicat 默认连接根本扛不住建表中间态 - Navicat 的“设计表”不校验
innodb_log_file_size是否足够支撑大 DDL，容易因日志空间不足中途失败
外键约束让 MODIFY COLUMN 直接报错
哪怕你只改一个非外键字段的长度，只要这张表是任何外键的父表或子表，MySQL 严格模式下就会拒绝执行 MODIFY COLUMN，报错：Cannot change column 'xxx': used in a foreign key constraint。Navicat 不会自动帮你 DROP FOREIGN KEY 再重建，它生成的 SQL 是字面翻译，没加依赖解析逻辑。
必须手动拆解操作：
- 先查外键名：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table'; - 删外键：
ALTER TABLE `child_table` DROP FOREIGN KEY `fk_name`; - 再改字段：
ALTER TABLE `your_table` MODIFY COLUMN `col` VARCHAR(255) NOT NULL; - 最后重建外键（注意
ON DELETE和字段类型必须和原来一致）
Navicat 连接参数没调，等锁超时就断
Navicat 默认用普通会话执行 DDL，innodb_lock_wait_timeout 是 50 秒，而大表加索引或改字段常需数分钟。一旦后台事务被其他连接阻塞，Navicat 就在客户端直接报错退出，但 MySQL 实际还在后台跑着 DDL——你看到的“卡住”，其实是客户端放弃等待了。
临时缓解（仅限测试环境）：
- 进 Navicat 连接属性 → SSH/高级 → 在“初始化命令”里加：
SET SESSION innodb_lock_wait_timeout = 3600; - 同时设
SET SESSION net_write_timeout = 7200;防止导出数据时被服务端断连 - 但别长期这么干——超时调太大可能让长事务滞留更久，加剧锁竞争
真正安全改大表结构，绕开 Navicat GUI
超过 500 万行的表，任何通过 Navicat “设计表”点保存的操作都属于高危行为。它无法做在线变更、不能分批处理、也不支持失败回滚。
生产环境应切换到命令行工具：
- 用
pt-online-schema-change：基于影子表+触发器，业务零感知，支持暂停/续传/限速 - MySQL 8.0+ 可尝试
ALTER TABLE ... ALGORITHM=INSTANT（仅限加列、重命名、修改注释等极轻量操作） - 如果必须用 Navicat 导出再重建：先导出表结构（不导数据），清空原表，导入结构，再用
LOAD DATA INFILE分批次导入，最后补索引
最易被忽略的一点：Navicat 的“保存”动作不会告诉你当前 ALTER 正在走的是 COPY 还是 INPLACE 算法——而这个判断完全取决于你改的字段类型、MySQL 版本、以及 old_alter_table 参数值，不看 SHOW ENGINE INNODB STATUS 根本意识不到它已经在后台拷表了。
