Navicat执行ALTER TABLE卡住或报错本质是表被其他事务长时间持有写锁导致等待超时；需查INNODB_TRX和INNODB_LOCK_WAITS定位锁源，避免盲目KILL；外键约束、缓存未刷新、大表加索引超时等问题均需针对性处理。
Navicat 执行 ALTER TABLE 卡住或报错 Lock wait timeout exceeded
本质是表被其他事务长时间持有写锁，navicat 的 ddl 操作在等锁时超时了。不是 navicat 本身有问题，而是它默认用普通连接执行 ddl，没做锁等待控制。
- 先查谁在锁表：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60;
- 再看锁冲突：
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
- 别直接 kill 掉长事务——先确认它是不是业务关键操作（比如未提交的订单导入）
- 临时解法：在 Navicat 连接属性里把
wait_timeout和innodb_lock_wait_timeout调大（如设为 300），但只是缓解，不治本
Navicat 点“保存”改字段类型，提示 Cannot change column 'xxx': used in a foreign key constraint
MySQL 严格模式下，即使你没动外键字段，只要修改的列参与了任何外键定义（哪怕只是被引用），ALTER TABLE ... MODIFY COLUMN 就会拒绝执行。
- 必须先删外键：
ALTER TABLE `child_table` DROP FOREIGN KEY `fk_name`;
- 再改字段：
ALTER TABLE `parent_table` MODIFY COLUMN `id` BIGINT UNSIGNED NOT NULL;
- 最后重建外键（注意字段类型、约束名、ON DELETE 行为要和原来一致）
- Navicat 的“设计表”界面不会自动帮你处理外键依赖，它生成的 SQL 是直译操作，不会加前置/后置逻辑
用 Navicat 向大表加索引，执行几小时不动，连接还断了
MySQL 5.6+ 虽支持在线 DDL，但加索引仍需对整表扫描并排序，期间会持续持有 MDL（metadata lock），阻塞后续 DML；Navicat 默认的查询超时（net_read_timeout）往往比建索引时间短，导致客户端主动断连，但服务端仍在后台运行。
- 改用命令行 +
pt-online-schema-change（Percona Toolkit）更稳妥，它通过影子表+触发器实现真正无锁 - 如果必须用 Navicat，先在会话里调高超时：
SET SESSION innodb_lock_wait_timeout = 3600; SET SESSION net_write_timeout = 7200;
- 加索引前用
EXPLAIN FORMAT=JSON看下表数据量和主键分布，千万级以上的表别在业务高峰期操作
Navicat 提示 Unknown column 'xxx' in 'field list'，但字段明明存在
常见于 Navicat 缓存了旧的表结构元数据，尤其在手动执行过 RENAME TABLE 或跨库复制后，客户端没刷新缓存就点“设计表”。
- 右键连接 → “刷新”（不是刷新数据库，是刷新整个连接）
- 或者关闭 Navicat，删掉本地缓存目录：
~/Library/Application Support/PremiumSoft CyberTech/Navicat Premium/Profiles/（macOS）或%APPDATA%\PremiumSoft\Navicat Premium\Profiles\（Windows） - 别信“设计表”界面右上角显示的字段列表——它读的是本地缓存，不是实时
SHOW COLUMNS
DDL 操作的不可见性最麻烦：锁在哪、事务卡在哪、缓存是否同步，全得靠查系统表和日志交叉验证。Navicat 图形界面省事，但也藏得最深。
