外键设置ON DELETE CASCADE是否合理？适用场景及风险咨询

结论 #

你对级联外键规则的理解是正确的，你的实际业务场景非常适合使用ON DELETE CASCADE，不需要额外配置ON UPDATE规则。

• 关于ON UPDATE的判断完全准确：你所有表用的都是自增主键，业务逻辑中不会修改主键值，ON UPDATE规则完全没有触发机会，属于冗余配置，不需要加。
• ON DELETE CASCADE本身不存在风险，风险只来自它是否匹配你的业务实体关系：

  之前举例的公司-员工场景不适用，是因为员工是独立实体，和公司是关联而非从属关系，删除公司不代表员工数据需要一并销毁，这时候级联删除会造成非预期的数据丢失。
  你提到的两种场景是否适用可以单独判断：

  1. 公司-客户场景：如果业务规则是删除公司就必须同时清空该公司的所有客户数据，那加ON DELETE CASCADE没有任何风险；如果客户数据需要单独留存归档，就不要用，改为手动删除或者归档逻辑即可。
  2. 「用户-站点方案-建筑-楼层-房间」的树状结构：这是典型的强从属关系，下层实体的存在完全依附于上层实体，没有站点的建筑、没有楼层的房间都没有业务意义，完全符合级联删除的语义，非常适合使用。
• 相比你之前手动逐层删除的做法，用ON DELETE CASCADE有明显优势：
  1. 避免手动写SQL时顺序错误、遗漏子表，导致产生孤儿数据
  2. 级联删除由数据库在单个事务内执行，要么全部删除成功要么全部回滚，数据一致性比自己手动实现多层删除更可靠
  3. 依赖层级越深，节省的开发和维护成本越高，不需要每次调整表结构都同步修改删除逻辑
     你已经在GUI层做了多层删除确认提示，已经覆盖了绝大多数误删顶层数据的风险。如果需要更高的安全性，可以给核心表增加软删除字段（比如is_deleted）替代硬删除，或者定期做全量备份即可，不需要因为担心误删否定级联删除的价值。

内容的提问来源于stack exchange，提问作者Mawg