删字段前须人工检查视图、存储过程、ORM代码及索引/外键依赖，Navicat不自动检测；删后需手动清理关联索引与外键，新增字段应避开MySQL 8.0+保留字。
直接删字段前，先确认它没被任何地方引用
mysql 不会自动检查字段是否在视图、存储过程、触发器或应用代码里被用到。你执行 drop column 成功了，但第二天应用报错 unknown column 'old_field' in 'field list'，这种问题很难回溯。
- 用
SELECT * FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_field%'扫描视图 - 查存储过程和函数：
SELECT ROUTINE_NAME, ROUTINE_DEFINITION FROM information_schema.ROUTINES WHERE ROUTINE_DEFINITION LIKE '%old_field%' - Navicat 本身不提供跨对象依赖分析，别依赖它的“右键删除”弹窗提示
- 如果项目用了 ORM（比如 Laravel 的 Eloquent 或 Django ORM），字段名可能硬编码在模型或迁移文件里，得手动 grepping
Navicat 里删字段的两种操作路径及其风险差异
Navicat 提供图形化修改表结构，但底层执行方式不同，直接影响锁表现和失败概率。
- 在表设计界面勾掉字段 → 点“保存”：Navicat 默认走
ALTER TABLE ... DROP COLUMN，对大表会锁全表（尤其 MySQL 5.6 及更早版本），线上库慎用 - 手动写 SQL 执行：
ALTER TABLE `users` DROP COLUMN `tmp_remark`—— 和上一条本质一样，但你能控制时机、加注释、进变更记录 - 想避免长锁？只能用 pt-online-schema-change 或 MySQL 8.0+ 的
ALGORITHM=INSTANT（仅限某些操作，删字段不支持 INSTANT） - Navicat 的“生成 SQL”按钮常被忽略：点开它，先看它打算执行什么语句，再决定是否真点“保存”
删字段后索引/约束没自动清理，导致后续 DDL 报错
字段删了，但基于它的唯一索引、联合索引、外键约束还挂着，MySQL 不会自动删——这是最常被跳过的一步。
- 删字段前，先查它关联的索引：
SHOW INDEX FROM `orders` WHERE Column_name = 'legacy_status' - 如果有结果，得先用
DROP INDEX idx_legacy ON orders手动删索引，再删字段 - 外键更麻烦：
SELECT CONSTRAINT_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_NAME='orders' AND COLUMN_NAME='legacy_status'，拿到名字后执行ALTER TABLE orders DROP FOREIGN KEY `fk_orders_legacy` - Navicat 表设计界面里，字段右侧的“索引”“外键”小图标是灰色的，不会高亮提醒你有依赖，得自己查
MySQL 8.0+ 的隐藏坑：系统字段名冲突与保留字检测变严
新版 MySQL 对字段名校验更严格，删完一个字段，紧接着加个新字段，可能因为名字撞了系统保留字或内部字段而失败。
- 比如字段名叫
rank、json、admin，在 MySQL 8.0.22+ 会被视为潜在保留字，即使没报错，后续用ORDER BY rank也得加反引号 - 删字段后新增字段时，Navicat 有时会默认填入类似
new_field这种名字，但如果你实际想填group，它不会警告，直到你点保存才报You have an error in your SQL syntax - 安全做法：新增字段前，先查
SELECT keyword FROM information_schema.KEYWORDS WHERE reserved = 1，避开返回结果里的词 - Navicat 的“字段名自动补全”功能在新版里容易误导人，关掉它更稳妥（设置 → 编辑器 → 取消勾选“启用字段名自动完成”）
删字段不是点一下就完的事，真正耗时间的是前后验证：删之前扫依赖，删之后查索引残留，加新字段前核对命名合规性。Navicat 让操作变快，但也让这些检查更容易被跳过。
