先查锁再处理：执行SHOW PROCESSLIST，若State为Waiting for table metadata lock，说明有未提交事务占用元数据锁；查information_schema.innodb_trx获取trx_mysql_thread_id，确认属自身后KILL对应ID进程。
navicat 可视化建表卡死，大概率不是你手慢，而是元数据锁没释放或 gui 封装层在等一个永远不会来的响应。
SHOW PROCESSLIST 查到 Waiting for table metadata lock 怎么办
建表、改字段、删表时卡在「执行中」，尤其是小表也卡，先连上数据库跑一句：SHOW PROCESSLIST;。重点看 State 列 —— 如果出现 Waiting for table metadata lock，说明有活跃事务占着锁没提交。
- 查锁定源头：
SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'RUNNING';，关注trx_mysql_thread_id - 确认该线程的
User和db是你自己，再执行：KILL 43043887;（把 ID 换成实际值） - 别直接 KILL 所有 Sleep 状态进程，
State为Sleep的通常是空闲连接，杀错可能中断别人事务
Navicat 自动保存触发 ALTER TABLE 卡死的根源
点「保存」建表或改字段时，Navicat 默认生成 ALTER TABLE 语句并执行。但这个操作需要获取表的元数据独占锁，而任何未提交的事务（哪怕只是 BEGIN 后没 COMMIT）都会让锁一直挂着。
- 避免方式：建新表时不勾选「自动保存」，先用「预览 SQL」确认语句，再手动复制到查询窗口执行
- 如果已卡住，不要反复点保存或关闭窗口 —— 这可能让锁状态更混乱；优先用
SHOW PROCESSLIST定位并 KILL - 开发环境建议关掉「自动保存」：设置 → 常规 → 取消勾选「修改对象结构后自动保存」
远程 MySQL + SSH 隧道导致建表假死怎么破
通过 SSH 连远程库时，Navicat 把 ALTER TABLE 请求全塞进隧道里转发，一旦网络抖动或 sshd 负载高，命令就卡在「等待响应」状态，界面看起来像冻结了。
- 验证是否是隧道问题：本地直连同台 MySQL（跳过 SSH），重复建表操作 —— 如果不卡，基本可定位
- 临时解法：改用命令行
mysql客户端连，执行CREATE TABLE或ALTER TABLE，绕过 Navicat 的隧道封装 - 长期建议：在 SSH 配置里加
ServerAliveInterval 30和TCPKeepAlive yes，防止中间链路静默断开
真正麻烦的不是卡住本身，而是很多人在卡住后立刻重启 Navicat 或重连 —— 这反而会让未释放的锁残留更久。先查锁、再动手，比狂点「取消」有用得多。
