navicat“设计表”点保存没反应，先看执行日志有没有sql；它生成alter table语句，若漏类型（mysql）、缺using（pg）、sqlite重建表失败等会导致静默失败，需查查询窗口确认真实sql及报错。
navicat“设计表”点保存没反应，先看执行日志有没有sql
navicat 不是直接改内存结构，而是生成并执行 alter table 语句。如果点保存后什么都没发生，最该做的不是反复刷新，而是打开查询窗口（ctrl+shift+q），勾选「显示运行的 sql」——它会记录所有设计器背后发出的真实语句。
常见静默失败场景：
- MySQL 中字段重命名用了
CHANGE COLUMN，但 Navicat 漏写了新列类型（比如只写CHANGE COLUMN name title，缺了VARCHAR(50)），语句语法错误，执行失败但 UI 不报错 - PostgreSQL 修改列类型（如从
TEXT改成INT）必须带USING表达式，Navicat 不自动生成，直接保存会触发cannot cast type text to integer错误 - SQLite 不支持
DROP COLUMN，Navicat 会尝试重建表，一旦原表有外键或PRAGMA foreign_keys = ON，操作就中断且无明确提示
右键“刷新表”不更新字段，是因为它根本不管结构
很多人卡在这一步：ALTER TABLE 成功执行了，但右键表名 → 「刷新表」，字段还是旧的。这是因为「刷新表」只重新拉取**当前页的数据行**，完全不查元数据——它不会触发 DESCRIBE table_name 或 SELECT * FROM information_schema.columns。
真正该点的是两个地方：
- 在对象树里，右键数据库或 schema → 「刷新」：强制重载整个元数据缓存
- 或者，在表上右键 → 「设计表」→ 再次打开设计器：这时 Navicat 会重新读取结构，如果之前改成功了，就能看到新字段
注意：Navicat 16+ 默认启用元数据缓存，改完结构不手动刷新 schema 层，设计器和字段列表大概率还显示旧快照。
保存卡死在“正在保存”，大概率是元数据锁（metadata lock）
点保存后界面假死、进度条不动、关不掉窗口——这不是 Navicat 崩溃，而是它的 ALTER TABLE 被阻塞在等待表级元数据锁。典型表现是执行 SHOW PROCESSLIST 后看到状态为 Waiting for table metadata lock 的长连接。
原因通常是：
- 另一个会话正持有该表的未提交事务（哪怕只是
SELECT ... FOR UPDATE） - 有慢查询正在扫描这张表，还没释放读锁
- MySQL 5.7 以前版本对大表
ALTER会锁全表，期间所有 DML 都排队
临时解法：用 KILL [id] 干掉阻塞源进程；长期建议避免在业务高峰期做 DDL，或用 ALGORITHM=INSTANT（MySQL 8.0.12+）减少锁粒度。
改完结构，后续 INSERT 却失败，别急着怪 Navicat
表结构明明改成功了（DESCRIBE table_name 能看见新字段），但应用插入数据时却报 Column 'xxx' cannot be null 或 Unknown column —— 这类问题往往不在 Navicat，而在你没意识到的隐性约束上：
- 新增了
NOT NULL字段但没设DEFAULT，所有 INSERT 必须显式提供值，否则被拒绝 - 视图或存储过程里硬编码了旧字段名，结构变了但上层逻辑没同步，INSERT 到视图就直接报错
- 应用代码用了预编译语句（JDBC/ODBC），驱动缓存了旧的列定义，重启连接或清空 PreparedStatement 缓存才能识别新字段
- MySQL 自动提交模式被关闭（
SELECT @@autocommit返回 0），而ALTER TABLE本身会触发隐式提交，导致后续 INSERT 在新事务中运行，若连接复用出问题，可能静默丢弃
DDL 和 DML 混在同一连接里，尤其在调试阶段，是最容易被忽略的坑——结构变了，但环境状态没跟上。
