Navicat支持直接重命名字段，但其“设计表”界面使用CHANGE COLUMN语法，需手动补全原字段类型（如VARCHAR(100) NOT NULL），否则可能隐式修改类型导致截断错误；更安全的方式是MySQL 8.0+下用RENAME COLUMN语句。
navicat 本身不自动降低重构风险，但能帮你把高风险操作“显性化”——只要你不跳过它提示的 sql 预览和权限检查。
重命名字段时为什么 Navicat 会悄悄改错类型？
Navicat 的“设计表”界面里点字段名改名，背后实际执行的是 CHANGE COLUMN，不是 RENAME COLUMN（MySQL 8.0+ 才有后者）。这意味着你必须手动补全原字段的完整定义，否则 Navicat 会用默认类型（比如把 VARCHAR(100) 变成 VARCHAR(255)）或触发隐式转换。
- 错误现象：
ERROR 1265: Data truncated for column 'name'或字段长度莫名变宽/变窄 - 正确做法：在“字段名”列填新名后，务必在“类型”列**重新输入原类型全称**，例如
VARCHAR(100) NOT NULL - 更安全的替代：直接写 SQL，用 MySQL 8.0+ 的
RENAME COLUMN old_name TO new_name，不涉及类型重声明
模型同步（Model Sync）真能避免线上结构漂移吗？
不能自动避免，但能暴露漂移。Navicat 的模型同步本质是比对“本地模型文件（.mwb）”和“目标库的 INFORMATION_SCHEMA”，生成差异 SQL。它只负责告诉你“哪里不一致”，不保证执行安全。
- 常见坑：同步前没确认连接账号有
SELECT权限访问INFORMATION_SCHEMA.KEY_COLUMN_USAGE—— 外键会被忽略，同步脚本漏掉约束 - MySQL 8.0+ 必须启用
show_compatibility_56=ON，否则 Navicat 拿不到完整外键元数据，ER 图和同步都失效 - 建议流程：先用
mysqldump --no-data导出线上 DDL → 用 Navicat 导入为模型 → 再做同步，比直接连生产库比对更可控
哪些 ALTER 操作在 Navicat 里点一下就锁表？
Navicat 不提示锁级别，但以下操作在 MySQL 5.7+ 仍大概率触发 LOCK=EXCLUSIVE，期间表不可读写：
-
DROP COLUMN：即使 InnoDB 支持 online DDL，删字段也需重建表（除非用ALGORITHM=INSTANT，仅限 MySQL 8.0.12+ 且字段非主键/索引） - 给已有数据的字段加
NOT NULL且未设DEFAULT：Navicat 默认不加DEFAULT值，执行卡住并报错ERROR 1138 - 修改字段类型导致精度丢失：如
CHANGE COLUMN score score TINYINT（原为INT），强制 COPY - 删除主键：InnoDB 必重建聚簇索引，Navicat 生成的
DROP PRIMARY KEY无ALGORITHM=INPLACE提示
团队协作时，Navicat 的“同步”动作该谁来触发？
不能由任意成员在共享连接上直接点“同步”。模型同步应作为 CI 流程的一环，而非手工操作。
- 危险行为：A 在 Navicat 里改了本地模型 → 点“同步到生产” → B 正在跑报表，查询被锁死
- 推荐做法：所有结构变更必须提交
.sql脚本到 Git，由 DBA 审核后，在预发布环境执行；Navicat 仅用于生成初稿 SQL，不直连生产 - 真正需要同步的，是 Navicat On-Prem Server 上的
.mwb文件和查询收藏夹——它们应和代码库保持同分支、同 Tag
最易被忽略的点：Navicat 的“设计表”操作不会记录谁在什么时候改了什么。一旦出问题，你只能靠 binlog 或审计日志回溯，而它本身不提供操作审计。别把它当协作工具用，只当它是 SQL 草稿本和可视化校验器。
