Navicat中设置ON DELETE/UPDATE CASCADE失败，根本原因是MySQL拒绝执行ALTER语句，常见于被引用字段无主键/唯一索引、字段类型或字符集不一致、表引擎非InnoDB、外键检查被禁用等。
navicat 里选 on delete cascade 或 on update cascade 不是点一下就完事——它依赖底层外键定义是否合法，且一旦设错，删数据可能连带清空多张表，不可逆。
为什么点完 Cascade 保存却失败
常见错误现象：Cannot add or update a child row: a foreign key constraint fails 或直接无提示静默退回。根本原因不是 Navicat 拒绝，而是 MySQL 拒绝执行 ALTER 语句。
- 被引用字段（如
users.id）没有PRIMARY KEY或UNIQUE约束——必须有，不能只是普通索引 - 子表外键字段和父表被引用字段类型不完全一致：比如
INT对INT UNSIGNED、VARCHAR(50)对VARCHAR(100)、字符集一个是utf8mb4_unicode_ci，另一个是utf8mb4_general_ci - 两张表引擎不是都为
InnoDB（MyISAM完全忽略外键定义，连报错都不会有） - Navicat 连接配置的「高级」页里 init command 填了
SET FOREIGN_KEY_CHECKS = 0，导致约束检查被全局关闭
在「外键」标签页正确填 Cascade 的操作路径
别在关系图里拖线后双击就填——那只是画图，不生效。必须进真实结构编辑器：
- 右键子表 → 设计表 → 切到
外键标签页 - 点
+添加 → 在「更新规则」下拉选CASCADE，「删除规则」同理 - 「引用表」必须手动选对目标表（不能靠名字猜），「引用字段」必须点开下拉选中具体字段名（不是输进去）
- 名称建议用规范格式，比如
fk_orders_user_id_to_users_id，避免 Navicat 自动生成带空格或特殊字符的名（PostgreSQL 会因此在 ER 图里漏读）
Cascade 实际行为与隐性风险
ON DELETE CASCADE 看似省事，但 Navicat 的 ER 图只用红色线标出它，而 ON UPDATE CASCADE 完全不显示颜色区分——你得自己记住哪条线开了什么级联。
- MySQL 执行
DELETE FROM users WHERE id = 123时，会自动删掉orders.user_id = 123的所有行，再删user_profiles.user_id = 123……只要外键链存在且都开了 CASCADE - 没有事务包裹的批量删除（比如 Navicat 的「表→清空表」）不会触发 CASCADE，它走的是
TRUNCATE，直接跳过外键检查 - 如果父表字段被
UPDATE，且开了ON UPDATE CASCADE，所有子表对应外键值会同步改——但若子表该字段上有唯一索引，可能因冲突导致整个 UPDATE 失败
验证 Cascade 是否真生效
别信 ER 图连线颜色，也别信 Navicat 底部状态栏的“已保存”。最可靠的是查元数据：
- 执行
SHOW CREATE TABLE `orders`，确认输出里有类似CONSTRAINT `fk_orders_user_id_to_users_id` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE ON UPDATE CASCADE - 查系统表：
SELECT UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND CONSTRAINT_NAME = 'fk_orders_user_id_to_users_id' - 在 Navicat 的表结构页，切换到
Relationships标签页——这里只读，但能确认约束是否存在；如果为空，说明 Cascade 根本没建成功
真正麻烦的不是怎么点 Cascade，而是业务上是否真需要它。一个 ON DELETE CASCADE 可能让你删一条用户记录，顺手干掉三年订单、日志、通知……而 Navicat 不会弹窗二次确认。
