直接删父表失败是因为外键约束强制保护参照完整性，必须先处理子表依赖；安全做法是用临时表收集全部待删id，再按依赖深度从深到浅分步删除，并全程包裹事务确保原子性。
不能直接用 DELETE FROM parent WHERE id IN (...)，否则会因外键约束报错 ERROR 1451。
为什么存储过程中直接删父表会失败
外键约束阻止父表记录被删除，除非对应子表记录已不存在。存储过程里如果只写一句 DELETE FROM orders WHERE id IN (@ids)，数据库会立刻拒绝执行，抛出 Cannot delete or update a parent row 错误。这不是语法问题，是引擎强制的参照完整性保护。
- 错误现象：执行后返回 0 行受影响，或直接报
ERROR 1451 - 常见误区：以为加事务就能绕过约束——不行，约束检查在语句执行前就触发
- 根本原因：SQL Server / MySQL / PostgreSQL 都默认禁止“悬空外键”，必须显式处理依赖链
安全做法：先收全 ID，再分表逆序删
核心是把“递归查子节点”和“按依赖层级删表”拆成两步，避免循环依赖和中间状态不一致。适用于 MySQL 5.7+、SQL Server、PostgreSQL（不含递归 CTE 的旧版本）。
- 第一步：用临时表存所有待删 ID（含父、子、孙…）
例如：CREATE TEMPORARY TABLE _to_delete_ids (id BIGINT PRIMARY KEY); INSERT INTO _to_delete_ids SELECT ... - 第二步：按依赖深度从深到浅删——先删最末端子表（如
order_items），再删中间层（如orders） - 每步都用
JOIN或IN关联临时表，确保只删目标记录，不波及其他数据 - 全程包裹在
BEGIN TRANSACTION中，任一步失败可整体回滚
MySQL 8.0+ 可用 WITH RECURSIVE，但不能直删
MySQL 允许用 WITH RECURSIVE 查出完整 ID 集合，但 DELETE ... WHERE id IN (WITH ...) 会报语法错误。必须拆开：
- 先执行：
INSERT INTO _to_delete_ids SELECT id FROM (WITH RECURSIVE ...) AS t; - 再执行：
DELETE o FROM orders o INNER JOIN _to_delete_ids t ON o.id = t.id; - 注意：
cte_max_recursion_depth默认 1000，若树太深需 SET 临时调高，否则报ERROR 3636
别碰 ON DELETE CASCADE 和动态拼 SQL
生产环境几乎不该启用 ON DELETE CASCADE，它让一次误删扩散成全链路丢失；而拼接 @sql 字符串执行（如 EXEC(@sql)）极易引发 SQL 注入，且无法参数化，@WHEREA = '1,2,3' 这种传参方式实际只会匹配字符串字面值，不是三个 ID。
- 级联删除不可控：删一条订单可能连带清掉用户、地址、日志等无关表
- 拼 SQL 风险高：哪怕加了
QUOTENAME，也无法完全防住嵌套恶意输入 - 真正安全的路径只有两条：明确的分步 + 事务，或预设好约束的单点级联（仅限极简场景）
复杂点在于依赖链长度不确定时，临时表要建多少层 JOIN、递归深度是否超限、事务锁范围是否影响并发——这些没法靠模板解决，得看具体表结构和数据分布。
