递归CTE不能直接用于UPDATE，必须分两步：先用递归CTE查出子节点ID，再通过IN或JOIN更新；多数数据库不支持UPDATE中嵌套递归CTE，PostgreSQL 14+除外。
用递归CTE一次性更新整棵子树
直接在UPDATE里写递归逻辑行不通，SQL标准不支持UPDATE + WITH RECURSIVE的组合。必须拆成两步：先用递归CTE查出所有目标子节点ID，再用IN或JOIN完成更新。
常见错误是试图写 UPDATE t SET status = 'done' FROM (WITH RECURSIVE ...) AS r WHERE t.id = r.id —— 多数数据库（如PostgreSQL 12之前、MySQL 8.0）会报错“不能在UPDATE的FROM子句中引用递归CTE”。
- PostgreSQL 14+ 支持
WITH RECURSIVE ... UPDATE语法，但需确保版本够新 - MySQL 8.0 只允许递归CTE用于SELECT，UPDATE必须用临时表或子查询包装
- SQL Server 的
UPDATE ... FROM (CTE)是安全的，但CTE定义必须放在UPDATE之前且独立
避免父节点被重复更新或漏更新
递归起点选错会导致整个子树范围偏差。比如想更新ID=5的所有后代，但CTE里写成 WHERE parent_id = 5（只查直接子节点），而不是 WHERE id = 5 作为根再向下找子节点。
典型场景：状态字段要同步到整个分支，但父节点本身也要更新（比如审批通过后，整条流程标记为done）。这时CTE的anchor member必须包含根节点自身。
- 正确anchor：
SELECT id FROM tree WHERE id = 5 - 错误anchor：
SELECT id FROM tree WHERE parent_id = 5 - 递归部分必须用
JOIN tree ON t.parent_id = r.id（自上而下），不能反向
性能差？检查索引和层级深度
没索引时，递归CTE每层都要全表扫描，10层深可能触发数万次IO。实际执行计划里如果看到“Seq Scan on tree”反复出现，基本可以确定是瓶颈。
- 必须有复合索引：
CREATE INDEX idx_tree_parent_id ON tree(parent_id, id) - 单列
parent_id索引效果有限，因为递归过程需要快速定位每个节点的所有子节点 - 超过1000级的树建议拆成闭包表（Closure Table），递归CTE在深度>50时已明显变慢
MySQL 8.0下必须绕开的语法坑
MySQL不允许在UPDATE语句中直接嵌套递归CTE，哪怕用子查询包装也不行。报错信息通常是 ERROR 1288: The target table t of the UPDATE is not updatable 或类似提示。
可行方案只有两种：临时表 or 变量模拟递归。临时表更可靠，变量方案在并发下容易错乱。
- 安全写法：先
CREATE TEMPORARY TABLE tmp_ids AS WITH RECURSIVE r AS (...) SELECT id FROM r，再UPDATE tree SET status = 'done' WHERE id IN (SELECT id FROM tmp_ids) - 禁止写法：
UPDATE tree SET status = 'done' WHERE id IN (WITH RECURSIVE ...)（语法错误） - 注意临时表生命周期，存储过程里用完记得
DROP TEMPORARY TABLE
max_recursion_depth限制。上线前务必用 SELECT 版本跑一遍，加 LEVEL 或 path 字段人工检查。 
