推荐优先使用数据库外键级联删除（ON DELETE CASCADE），需确保字段类型、字符集、引擎一致并按依赖顺序建表；若禁用外键则用JPA事务内控制删除顺序；紧急时可临时关外键检查但严禁用于生产。
Java 中操作 MySQL 多表关联删除时，级联约束和外键限制的处理方式取决于你选择的控制层级：数据库层（InnoDB 外键 + CASCADE）还是应用层（如 JPA 或手写 SQL 逻辑）。关键不是“能不能删”，而是“谁来保证一致性”——数据库强制执行，还是 Java 主动协调。
用数据库外键实现级联删除（推荐用于简单、强一致场景）
在建表时明确声明 ON DELETE CASCADE，让 InnoDB 自动清理下游记录。这是最直接、原子性最强的方式。
- 确保所有关联字段类型、字符集、引擎完全一致（例如都用
INT UNSIGNED，都用InnoDB）；否则外键创建会失败 - 按依赖顺序建表：先建祖父表（
scenario），再建父表（event），最后建子表（plan），并在子表外键中分别指定级联行为 - 示例语句：
ALTER TABLE event ADD CONSTRAINT fk_event_scenario FOREIGN KEY (scenario_id) REFERENCES scenario(id) ON DELETE CASCADE;ALTER TABLE plan ADD CONSTRAINT fk_plan_event FOREIGN KEY (event_id) REFERENCES event(id) ON DELETE CASCADE; - 注意：若
plan.scenario_id直接引用scenario.id，也需单独加一条外键并设ON DELETE CASCADE，否则删除scenario时仍会因该外键报错
用 JPA 实现应用层级联（适合复杂业务或需审计/拦截的场景）
当项目遵循《阿里巴巴 Java 开发手册》要求（禁用外键），或需要在删除前做校验、日志、补偿等逻辑时，应由 Java 控制整个链路。
- 使用
@OneToMany(cascade = CascadeType.REMOVE, orphanRemoval = true)配合@ManyToOne，JPA 会在事务内按依赖顺序发出多条 DELETE 语句 - 务必开启事务（
@Transactional），否则中间失败会导致数据不一致 - 若存在多路径引用（如
plan同时关联scenario和event），需手动控制删除顺序：先删plan，再删event，最后删scenario - 避免 N+1 查询：用
@Fetch(FetchMode.JOIN)或 JPQL 的JOIN FETCH一次性查出全部待删实体
绕过外键限制的临时方案（仅限紧急修复或迁移）
当无法修改表结构，又必须快速清理数据时，可临时关闭外键检查，但风险极高，仅限开发/测试环境。
立即学习“Java免费学习笔记（深入）”；
- 执行前先备份：
SET FOREIGN_KEY_CHECKS = 0; - 按反向依赖顺序执行 DELETE（先子后父）：
DELETE FROM plan WHERE scenario_id = ?;→DELETE FROM event WHERE scenario_id = ?;→DELETE FROM scenario WHERE id = ?; - 完成后立即恢复：
SET FOREIGN_KEY_CHECKS = 1; - ⚠️ 生产环境严禁使用：跳过约束可能留下脏数据，且不支持事务回滚中的外键状态还原
排查外键冲突的常见原因
遇到 Cannot delete or update a parent row 错误时，不要只看表面报错表，要顺藤摸瓜查完整引用链。
- 查清哪张表的哪个外键在拦路：
SELECT CONSTRAINT_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'plan'; - 确认被引用字段是否为主键或唯一索引：外键只能引用
PRIMARY KEY或UNIQUE字段 - 检查字段值是否匹配：比如
plan.scenario_id引用的是event.scenario_id（非主键），而event.scenario_id并未加唯一约束 → 这种设计本身就不合规，需重构 - 留意隐式外键：某些 ORM 框架（如 MyBatis）虽不建物理外键，但 SQL 逻辑仍存在依赖，此时错误表现为应用层异常而非 SQL 错误
