CTE不能直接DELETE，需通过DELETE...USING（PostgreSQL/SQL Server）或DELETE...IN子查询（MySQL 8.0+加嵌套包装）实现；递归删除须防环与深度爆炸，应设递归限制并精简字段、尽早WHERE剪枝。
CTE里不能直接DELETE，必须用WITH配合子查询
SQL标准中，WITH定义的CTE本身不支持直接跟DELETE语句（比如WITH cte AS (...) DELETE FROM cte会报错）。真正可行的是把CTE作为DELETE的“数据源”——即用DELETE ... FROM ... WHERE id IN (SELECT id FROM cte)或DELETE FROM t USING cte WHERE t.id = cte.id这类结构。
PostgreSQL和SQL Server支持DELETE ... USING语法，MySQL 8.0+只支持DELETE ... WHERE id IN (SELECT ...)（且子查询不能引用被删表，需加一层包装）。
- PostgreSQL示例：
WITH target AS ( SELECT id FROM comments WHERE post_id = 123 AND depth > 2 ) DELETE FROM comments USING target WHERE comments.id = target.id;
- MySQL 8.0+必须绕开“不能在子查询中修改目标表”的限制：
DELETE FROM comments WHERE id IN ( SELECT id FROM ( WITH target AS (SELECT id FROM comments WHERE post_id = 123 AND depth > 2) SELECT id FROM target ) AS tmp );
层级递归删除要小心循环引用和性能爆炸
用WITH RECURSIVE做树形结构的级联删除时，如果父子关系存在环（比如A→B→C→A），递归会无限进行，直到超出max_recursion_depth（MySQL）或statement_timeout（PostgreSQL），最终报错或超时。即使没环，深度过大（如>1000层）也会显著拖慢执行。
- 务必先加
MAXRECURSION 100（SQL Server）或设置cte_max_recursion_depth=1000（MySQL）防死循环 - 递归CTE中尽量只SELECT必要字段（尤其是主键），避免
SELECT *带入大文本字段，否则内存占用飙升 - 在
WHERE条件里尽早剪枝：比如WHERE parent_id IS NOT NULL AND depth ，比全量展开再过滤更高效
DELETE前必须验证CTE结果，别信“逻辑正确就安全”
写完带CTE的DELETE语句，第一件事不是执行，而是把CTE部分单独拿出来SELECT *跑一遍——确认它真的只命中你打算删的行。线上环境曾有人把WHERE post_id = ?写成WHERE post_id = 0，CTE查出全部评论，DELETE就清空了整个表。
- 递归CTE尤其容易误判：比如想删某条评论及其所有子评论，但忘了加起始条件
WHERE id = ? OR parent_id = ?，结果从根节点开始遍历，删掉整棵树 - 跨表关联时注意JOIN条件是否漏了
ON或写错字段名，导致笛卡尔积，CTE结果集远大于预期 - 用
EXPLAIN看执行计划：确认是否走了索引（特别是递归中的parent_id字段），避免全表扫描
替代方案：临时表比嵌套CTE更可控
当CTE逻辑复杂、涉及多层JOIN或需要多次引用时，用CREATE TEMP TABLE代替嵌套CTE反而更清晰、易调试、性能也更稳。临时表能加索引、能ANALYZE、能分步验证，而且不受“子查询不能改目标表”的限制。
- PostgreSQL示例：
CREATE TEMP TABLE to_delete AS WITH RECURSIVE tree AS ( SELECT id FROM comments WHERE id = 456 UNION ALL SELECT c.id FROM comments c JOIN tree t ON c.parent_id = t.id ) SELECT id FROM tree; DELETE FROM comments WHERE id IN (SELECT id FROM to_delete);
- 临时表命名加业务前缀（如
tmp_del_comments_2024）方便排查；执行完立刻DROP TABLE或依赖会话自动清理
递归深度大、条件多、要复用中间结果时，临时表几乎总是比硬塞进单个CTE更靠谱。别为了“炫技”牺牲可读性和安全性。
