递归CTE删除树形结构前必须先检查根节点是否被外键引用，否则直接删除会因FOREIGN KEY constraint failed失败；各数据库语法差异大，需按规则分步操作并预览结果。
用递归CTE删除树形结构前，必须确认根节点是否被其他表外键引用
直接执行递归删除却报 FOREIGN KEY constraint failed 是最常见的翻车点。PostgreSQL/SQL Server/SQLite 支持递归 CTE，但数据库不会自动帮你级联检查外键依赖——它只管查出子树，删的时候才撞墙。
实操建议：
- 先运行
SELECT COUNT(*) FROM other_table WHERE parent_id IN (SELECT id FROM tree_cte)，把递归查出的id集合拿去反查外键表 - 若存在引用，要么加
ON DELETE CASCADE（需有表结构修改权限），要么手动先删下游关联记录 - MySQL 8.0+ 虽支持递归 CTE，但默认不允许多层子查询嵌套在
DELETE ... USING中，得用临时表中转
DELETE 不能直接跟 WITH RECURSIVE，得用 JOIN 或子查询中转
很多人写成 WITH RECURSIVE t AS (...) DELETE FROM tree WHERE id IN (SELECT id FROM t)，这在 PostgreSQL 可行，但在 SQL Server 和 SQLite 中语法报错：CTE 必须紧邻其消费语句，且不能跨 DML 类型。
安全写法分两步：
- PostgreSQL：用
DELETE USING——WITH RECURSIVE t AS (...) DELETE FROM tree USING t WHERE tree.id = t.id - SQL Server：把 CTE 结果 INSERT 到临时表
#to_delete，再DELETE t FROM tree t INNER JOIN #to_delete d ON t.id = d.id - SQLite：同 SQL Server，或改用
DELETE FROM tree WHERE id IN (WITH RECURSIVE t AS (...) SELECT id FROM t)（仅限单列、无重复 ID 场景）
递归 CTE 的 anchor 和 recursive 部分字段顺序、类型必须严格一致
哪怕只是 id INT 和 id BIGINT 混用，或 anchor 返回 name TEXT 而 recursive 返回 NULL，某些数据库（如 SQL Server）会静默截断或报 Types don't match between the anchor and the recursive part。
关键检查项：
- anchor 查询和 recursive 查询的列数、名称、数据类型必须完全相同；建议显式 CAST，比如都写
CAST(id AS BIGINT) AS id - recursive 部分的 JOIN 条件必须指向父节点（如
ON t.parent_id = r.id），写反了会无限循环或漏删 - 加
MAXRECURSION 100（SQL Server）或search depth first（PostgreSQL）可防意外死循环，但不能替代逻辑校验
删除深度超过 100 层的树时，注意各数据库默认递归深度限制
SQL Server 默认 MAXRECURSION 100，超限直接中断并报错；PostgreSQL 默认无硬限制但可能 OOM；SQLite 由编译选项决定，通常 1000 级以内较稳。
应对方式：
- SQL Server：在 CTE 后加
OPTION (MAXRECURSION 0)（0 表示无限制），但务必提前确认树深，避免栈溢出 - PostgreSQL：设
WITH RECURSIVE t AS (...) SELECT * FROM t LIMIT 10000先抽样看是否收敛，再删；也可用search depth first+cycle子句防环 - 真正超深树（如组织架构 > 500 层），建议改用应用层迭代删除，每次删一层，更可控
递归删除最危险的不是语法写错，而是误判“哪些该删”——CTE 查出来的集合是否真等于业务语义上的子树？别跳过 SELECT 预览那一步。
