不能直接用ON DELETE CASCADE，因自引用表禁止该约束以防无限递归或整表误删；递归CTE需锚点定根、递归查下属（e.manager_id = d.id）、加防环和层级限制确保安全。
为什么不能直接用 ON DELETE CASCADE？
自引用表（比如员工表中 manager_id 指向同一张表的 id）无法在自身上定义 ON DELETE CASCADE 外键——多数主流数据库（PostgreSQL、SQL Server、MySQL 8.0+）都明确禁止这种自引用级联。强行加会报错，例如 PostgreSQL 报 ERROR: cannot create self-referencing foreign key with ON DELETE CASCADE。
这不是语法疏漏，而是防止无限递归或意外清空整张表。所以必须手动控制删除边界和顺序。
递归CTE怎么写才安全？
递归 CTE 的核心是分两步：先找「要删的根节点」，再层层向下找所有后代。但必须注意方向——自引用关系里，manager_id → id 表示“谁是我的下属”，所以删除某人时，要查的是以他为起点、顺着 manager_id 向下展开的所有节点。
错误写法是把递归条件写成 id = manager_id（这会向上找上司），正确方向是：
WITH RECURSIVE to_delete AS ( -- 锚点：你要删的那个人 SELECT id FROM employees WHERE id = 123 UNION ALL -- 递归：找所有 manager_id 等于上一层 id 的人（即下属） SELECT e.id FROM employees e INNER JOIN to_delete d ON e.manager_id = d.id ) DELETE FROM employees WHERE id IN (SELECT id FROM to_delete);
- 锚点必须是确定的单条记录或明确 ID 集合，避免误删
- 递归 JOIN 条件必须是
e.manager_id = d.id，不是e.id = d.manager_id - PostgreSQL 要求递归查询必须有
UNION ALL，且递归分支不能含聚合、GROUP BY、LIMIT - SQL Server 需显式加
OPTION (MAXRECURSION n)，否则默认只跑 100 层，超限报错Msg 530
如何防止误删和死循环？
自引用数据如果存在环（比如 A 管 B，B 管 C，C 又管 A），递归 CTE 会无限运行直到超限。生产环境必须加防护：
方案一：加层级限制 + 去重路径（PostgreSQL 示例）：
WITH RECURSIVE to_delete AS (
SELECT id, ARRAY[id] AS path, 1 AS depth
FROM employees WHERE id = 123
UNION ALL
SELECT e.id, d.path || e.id, d.depth + 1
FROM employees e
INNER JOIN to_delete d ON e.manager_id = d.id
WHERE NOT e.id = ANY(d.path) -- 防环：不重复访问已遍历节点
AND d.depth < 10 -- 防深递归
)
DELETE FROM employees
WHERE id IN (SELECT id FROM to_delete);
-
ARRAY[id]和NOT e.id = ANY(d.path)是 PostgreSQL 防环关键 - SQL Server 可用
STRING_AGG(id, ',') WITHIN GROUP (ORDER BY ...)模拟路径，但性能差，建议先用CHECK CONSTRAINT或应用层保证无环 - MySQL 8.0+ 不支持数组，需靠业务约束或额外临时表记录已访问 ID
执行前必须验证删除范围
千万别跳过预览步骤。递归 CTE 删除一旦执行就不可回退（除非有事务和备份）。
每次操作前，先运行 SELECT 版本确认范围：
WITH RECURSIVE to_delete AS ( SELECT id, name, manager_id, 0 AS level FROM employees WHERE id = 123 UNION ALL SELECT e.id, e.name, e.manager_id, d.level + 1 FROM employees e INNER JOIN to_delete d ON e.manager_id = d.id ) SELECT * FROM to_delete ORDER BY level, id;
- 看输出行数是否符合预期；特别检查 level=0 是否只有目标记录
- 观察是否有异常高 level 值（暗示深度过大或隐含环）
- 如果表大，先在 WHERE 中加
AND id IS NOT NULL避免 NULL 引发逻辑错误
递归删除真正的难点不在语法，而在对业务关系的理解是否准确——manager_id 是“我管谁”，不是“谁管我”。写错这一条，整个 CTE 就变成向上删光所有领导，而不是向下删干净整个团队。
