递归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

递归更新真正难的不是写法，而是确认“这棵树到底有没有环”——如果有循环引用（A→B→C→A），CTE默认不报错但会无限循环直到超时或达到max_recursion_depth限制。上线前务必用 SELECT 版本跑一遍，加 LEVEL 或 path 字段人工检查。