ON DELETE CASCADE是最直接的解法，需建表时显式声明、仅InnoDB支持、不可回滚单层动作、有递归深度限制（MySQL默认15层），软删除或异步队列更适合审计或复杂逻辑场景。
外键级联删除（ON DELETE CASCADE）是最直接的解法
如果数据库设计阶段就允许，直接在建表时定义 ON DELETE CASCADE 是最稳妥的方式。它让数据库自动处理子记录清理，避免应用层手动遍历和删除。
常见错误是只加了 FOREIGN KEY 约束但漏掉 ON DELETE CASCADE，结果删主表时仍报错 ERROR 1451 (HY000): Cannot delete or update a parent row。
- 必须确保存储引擎支持（MySQL 中仅
InnoDB支持，MyISAM不行） - 级联深度有限制：MySQL 默认最多 15 层，超深嵌套会报
ERROR 1292: Truncated incorrect DOUBLE value类似隐式转换错误（实际是递归限制） - 无法回滚单个级联动作——整条
DELETE要么全成功，要么全失败，不支持“删了一半发现不对再撤”
手写多表 DELETE 语句需严格按依赖顺序执行
没有级联时，必须人工保证删除顺序：先清子表，再删父表。顺序颠倒就会触发外键约束失败。
例如有三张表：orders → order_items → inventory_logs，正确顺序只能是：inventory_logs → order_items → orders。
- 用
SELECT COUNT(*)预查各表待删数量，防止误删过多（比如本想删一条订单，结果连带删了上千条日志） - MySQL 支持多表
DELETE语法，但仅限同一WHERE条件下的关联删除，不能跨多层跳级，例如不能用一条语句同时删orders和深层的inventory_logs - PostgreSQL 不支持多表
DELETE，必须拆成多条语句，并显式用BEGIN; ... COMMIT;包裹保证原子性
软删除替代方案更适合审计敏感场景
当业务要求保留删除痕迹（如财务、风控），硬删不可逆，应改用软删除：给主表加 is_deleted 字段，所有关联查询加 WHERE is_deleted = 0 过滤。
此时“同步删除”变成同步更新状态，彻底规避外键冲突和顺序问题。
-
is_deleted建议用TINYINT(1)或BOOLEAN，别用VARCHAR存 'true'/'false'——索引失效且易拼错 - 所有 JOIN 查询必须检查该字段，漏一处就可能查出已“删”的脏数据
- 定时任务归档历史数据时，仍需按依赖顺序物理清理，只是时机可控、可分批
触发器方案风险高，仅作兜底或特殊逻辑补充
用 BEFORE DELETE 触发器手动删子记录，看似灵活，实则容易埋坑。
典型问题是触发器内执行的 DELETE 又触发下一层触发器，造成无限递归或超出栈深度——MySQL 会报 ERROR 1429: Unable to connect to foreign data source（错误码误导，实际是递归超限）。
- 触发器里禁止调用存储过程做复杂操作，MySQL 对触发器内事务控制极弱
- 不同数据库对触发器并发行为处理不一致（如 PostgreSQL 允许行级锁控制，MySQL 更粗粒度）
- 上线前必须用真实数据量压测，小数据量测不出死锁或超时问题
真正需要复杂清理逻辑（比如删订单时还要通知库存服务、写 Kafka 日志），应该把清理动作移到应用层异步队列，而不是塞进数据库触发器。
