必须分三步操作：先删外键→再改字段名→最后重建外键；因MySQL禁止直接重命名被外键引用的列，否则报错ER_FK_COLUMN_CANNOT_CHANGE（1832）。
为什么直接改字段名会报“Cannot modify column used in a foreign key constraint”
这不是 Navicat 的 bug，而是 MySQL 服务端明确拒绝执行——ALTER TABLE ... CHANGE COLUMN 或 MODIFY COLUMN 操作一旦涉及被外键引用的列（比如 user_id），InnoDB 就会立即返回错误码 ER_FK_COLUMN_CANNOT_CHANGE（1832）。根本原因在于：外键依赖的列必须保持类型、字符集、排序规则、是否允许 NULL 等属性严格一致；重命名虽不改变语义，但 MySQL 认为这是“结构变更”，需先解除约束才能操作。
必须分三步：删外键 → 改字段 → 重建外键
Navicat 不会自动帮你做这三步，图形界面点“保存”只会生成单条 CHANGE COLUMN，必然失败。正确路径是手动控制 DDL 流程：
- 先在子表（引用方）中删除所有指向该字段的外键：右键子表 →「设计表」→「外键」选项卡 → 选中对应外键 → 点「-」删除 → 保存
- 再回到父表（被引用方），右键 →「设计表」→ 修改字段名（如
id→user_id）→ 保存（此时无外键阻碍，可成功） - 最后回到每个子表，重新添加外键：字段选新名字（如
user_id），被引用表选父表，被引用字段选新名字（如user_id），注意同步更新“更新时/删除时”行为
关键点：第二步改名后，第三步重建外键时，“被引用字段”下拉框里必须能看见新字段名；如果看不到，说明父表没真正保存成功，或字符集不一致导致元数据未刷新。
容易踩的坑：字段名变了，但外键定义里的旧名还残留
常见现象是：父表字段已改名为 user_id，但子表外键仍指向 id，导致插入时报 Cannot add or update a child row: a foreign key constraint fails。这不是 Navicat 同步延迟，而是你漏掉了第三步，或重建时没选对字段。
- 务必用
SHOW CREATE TABLE `child_table`验证子表外键定义中的字段名是否已更新 - 如果外键名是自动生成的（如
fk_orders_id），重命名父表字段后它不会自动改名，必须手动删掉再建 - 跨库外键更危险：被引用表在另一个库时，Navicat 可能无法在「被引用字段」下拉框中列出新字段，此时需切到 SQL 模式手动写
ADD CONSTRAINT
大表或批量操作时，别信“SQL 预览”就万事大吉
Navicat 的 SQL 预览只显示当前操作的语句，不会自动拼接前置的 DROP FOREIGN KEY 和后续的 ADD CONSTRAINT。哪怕你开了 Show SQL Preview before executing DDL statements，它也只预览“改字段”那一条。
- 对线上大表，建议把三步拆成独立 SQL，在查询窗口逐条执行，并加
ALGORITHM=INPLACE, LOCK=NONE（如果支持） - 改字段前先确认子表外键数量：
SELECT COUNT(*) FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'parent_table' AND REFERENCED_COLUMN_NAME = 'old_name' - 如果子表有几十个，别手点，用脚本生成 DROP/ADD 语句（例如从
INFORMATION_SCHEMA查出所有相关外键名和定义）
最常被忽略的是：改完字段名后，所有子表的外键约束都断开了，业务写入可能立刻报错——不是等你发现模型连线消失才出问题，而是第一条 INSERT 就失败。
