navicat结构同步完全忽略on delete cascade变更，因其比对引擎仅校验外键是否存在，不解析references子句中的级联选项；界面可选cascade但不同步生效，需手动执行drop/add foreign key ddl才能真实应用。
Navicat结构同步完全忽略ON DELETE CASCADE变更
它不比对、不生成、也不应用外键级联行为的任何修改——哪怕你在源库已执行ALTER TABLE orders ADD CONSTRAINT fk_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE，同步预览里也不会出现差异，更不会在目标库执行对应语句。根本原因在于：Navicat的结构比对引擎只校验外键约束“是否存在”，不解析REFERENCES子句后的ON DELETE或ON UPDATE部分。
为什么界面能选CASCADE但同步不生效
Navicat 16+ 的「设计表 → 外键选项卡」里第七列确实提供ON DELETE下拉菜单，但这个操作仅影响你当前手动编辑时的DDL预览，**不会触发结构同步任务自动识别或传播该变更**。常见静默失败场景包括：
- 源表外键已设
ON DELETE CASCADE，但目标表仍是RESTRICT，同步时 Navicat 不认为这是“结构差异” - 你手动在目标表点选了
CASCADE并点击保存，但底部状态栏没显示“执行成功”，实际ALTER TABLE ... DROP FOREIGN KEY+ADD FOREIGN KEY ... ON DELETE CASCADE未真正执行 - 源库导出的建表语句中
ON DELETE CASCADE被写在注释里，或因字段类型不匹配（如INTvsINT UNSIGNED）导致约束创建失败，Navicat 同步时跳过整条语句而不报错
验证级联设置是否真实存在
别信界面显示，直接查数据库输出：
- 运行
SHOW CREATE TABLE orders，确认结果中FOREIGN KEY定义末尾明确包含ON DELETE CASCADE - 若不存在，说明同步没做这事；若存在但级联不触发，检查父表引擎是否为
InnoDB、外键字段类型是否严格一致、父表被引用列是否有PRIMARY KEY或UNIQUE约束 - 用
SELECT CONSTRAINT_NAME, UPDATE_RULE, DELETE_RULE FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND COLUMN_NAME = 'user_id'查元数据——注意该视图在 MySQL 中对DELETE_RULE支持不稳定，SHOW CREATE TABLE才是唯一可信依据
真正起作用的实操路径
想让目标库具备和源库一致的级联行为，必须绕过结构同步，走显式 DDL：
- 先确认目标表外键名：
SELECT CONSTRAINT_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_NAME = 'orders' AND REFERENCED_TABLE_NAME = 'users' - 手动执行：
ALTER TABLE orders DROP FOREIGN KEY <code>orders_ibfk_1; ALTER TABLE orders ADD FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE - 大表操作前加
SET lock_wait_timeout = 30;防锁等待超时；MySQL 8.0.29+ 可加ALGORITHM=INSTANT避免重建聚簇索引
最易被忽略的一点：Navicat 从不校验你点选的ON DELETE值是否最终写进了INFORMATION_SCHEMA，它只负责把界面操作转成一次ALTER提交——而这次提交可能因权限、引擎、类型等任一条件不满足而静默失败。
