级联删除是双刃剑，仅适用于强生命周期绑定的父子关系；RESTRICT为默认安全选项，强制业务层决策；SET NULL适用于需保留子记录的弱关联场景；复杂业务推荐手动分步删除加显式事务。
级联删除不是“开了就完事”的开关，它是一把双刃剑——用对了省力，用错了删库跑路。 开启 ON DELETE CASCADE 后，DELETE FROM users WHERE id = 123 这条语句可能顺手干掉几百条日志、几千条订单明细，而你连事务回滚都来不及按。
什么时候必须用 ON DELETE CASCADE
只在满足「强生命周期绑定」的父子关系中使用。也就是说：子记录离开父记录就彻底失去业务意义，且不会被单独查询或归档。
- 用户表
users和其操作日志表user_logs：日志只为该用户存在，删用户即弃日志 - 订单表
orders和订单明细表order_items：明细脱离订单毫无上下文 - 临时会话表
session_data关联到users：会话本就是用户登录时动态生成的附属物
反例：客户表 customers 和订单表 orders —— 订单是独立商业凭证，需审计、对账、开票，不能随客户注销而消失。
为什么 RESTRICT 才是默认且更安全的选择
MySQL 和大多数数据库默认用 ON DELETE RESTRICT（或等价的 NO ACTION），不是因为懒，而是防误操作。
- 执行
DELETE FROM customers WHERE id = 456时，若该客户有 12 条订单，数据库直接报错：Cannot delete or update a parent row: a foreign key constraint fails - 这个错误强制你停下来思考：这些订单要怎么处理？是迁移归属、标记为“已注销客户”，还是走人工审核流程？
- 它把数据决策权交还给业务逻辑层，而不是交给一条 SQL 的隐式行为
很多线上事故源于开发环境开了 CASCADE，测试时没覆盖关联数据量大的场景，上线后批量删用户触发雪崩式删除。
SET NULL 是弱关联场景的务实解法
当子记录需要长期保留，但又允许与父记录“断亲”时，ON DELETE SET NULL 比硬编码一个“已注销”占位 ID 更干净。
- 博客文章表
posts外键引用作者users.id，作者注销后文章仍需展示，只需把author_id设为NULL - 项目表
projects中的manager_id允许为空，经理离职后项目可暂无负责人
注意前提：author_id 字段必须声明为 NULLABLE，否则建表会失败；且应用层代码要能正确处理 NULL 值（比如不渲染作者名、显示“匿名”）。
真正优雅的删除，往往不用级联
复杂业务里，最可控的方式仍是手动分步删 + 显式事务：
START TRANSACTION; DELETE FROM user_roles WHERE user_id = 123; DELETE FROM user_sessions WHERE user_id = 123; DELETE FROM users WHERE id = 123; COMMIT;
这样做的好处：
- 每一步可加条件过滤（如只删 30 天前的日志）、可加日志埋点、可做中间校验
- 便于写单元测试：mock 掉某一步，验证异常路径是否兜底
- DBA 审计时能一眼看清影响范围，而不是靠反向推导外键图谱
级联删除的“优雅”只存在于模型极简、关系极明确、且无审计合规要求的场景。一旦涉及财务、法律、历史追溯，手动控制才是底线。
