SQL Server中无法直接用递归CTE更新原表，必须先用临时表存储CTE结果，再通过游标逐行更新；MySQL 8.0+和PostgreSQL支持更简洁的递归CTE结合UPDATE语法。
SQL Server 用递归 CTE + UPDATE 配合游标更新路径字段
直接用递归 CTE 的结果 UPDATE 原表在 SQL Server 中不可行（CTE 不能出现在 UPDATE 的 FROM 子句右侧，除非是可更新视图或自联接场景），所以必须拆成两步：先用 CTE 构建完整层级顺序，再逐行更新。你看到的原始代码里用 #T 临时表承接递归结果、再用游标遍历，就是最稳妥的落地方式。
常见错误现象：Msg 4405, Level 16, State 1: View or function 'RootNodeCTEee' is not updatable because the modification affects multiple base tables. —— 这是因为试图对递归 CTE 直接执行 UPDATE，SQL Server 明确禁止。
- 锚点部分必须能唯一确定起点，比如
WHERE ORG_ID = @Id，不能写成IN (SELECT ...)或带聚合，否则递归初始化失败 - 递归 JOIN 条件必须是
ORG_INFO.ORG_PARENT_ID = RootNodeCTEee.ORG_ID（子查父 → 向下展开），写反成ORG_INFO.ORG_ID = RootNodeCTEee.ORG_PARENT_ID就只查出同级或上层，路径全乱 -
ORG_PARENT_PATH字段建议设为VARCHAR(512)或更大，避免拼接时被截断；更新前先UPDATE ORG_INFO SET ORG_PARENT_PATH = NULL清空旧值，防止脏数据干扰
MySQL 8.0+ 可用递归 CTE + UPDATE 关联子查询一步到位
MySQL 8.0 支持把递归 CTE 当作派生表参与 UPDATE，只要确保子查询返回单值且不涉及聚合即可。比起 SQL Server 的游标方案，它更简洁、也更容易调试。
使用场景：你要批量更新所有节点的 full_path 字段，格式为 '/1/2/5'，其中根节点路径是 '/1'，子节点追加自身 ID。
WITH RECURSIVE tree AS (
SELECT id, parent_id, CAST(CONCAT('/', id) AS CHAR(512)) AS full_path
FROM orgs WHERE parent_id IS NULL
UNION ALL
SELECT o.id, o.parent_id, CONCAT(t.full_path, '/', o.id)
FROM orgs o INNER JOIN tree t ON o.parent_id = t.id
)
UPDATE orgs u
JOIN tree t ON u.id = t.id
SET u.full_path = t.full_path;
注意点：
- 必须用
CAST初始化full_path类型，否则 MySQL 可能推导出过短长度，导致后续CONCAT截断 -
MAXRECURSION在 MySQL 里叫cte_max_recursion_depth，默认仅 100；如果树深超限，需先执行SET SESSION cte_max_recursion_depth = 500; - UPDATE 语句中不能出现窗口函数或 GROUP BY，否则报错
Invalid use of group function
PostgreSQL 要用 WITH RECURSIVE + UPDATE 的 RETURNING 技巧绕过限制
PostgreSQL 不允许在 UPDATE 的 FROM 中直接引用递归 CTE，但可以用 WITH 的“写入前计算”能力：先在 WITH 块里完成递归路径生成，再用其结果驱动 UPDATE，并通过 RETURNING 验证效果。
WITH RECURSIVE tree AS ( SELECT id, parent_id, '/' || id::TEXT AS path FROM orgs WHERE parent_id IS NULL UNION ALL SELECT o.id, o.parent_id, t.path || '/' || o.id::TEXT FROM orgs o JOIN tree t ON o.parent_id = t.id ) UPDATE orgs SET full_path = t.path FROM tree t WHERE orgs.id = t.id RETURNING orgs.id, orgs.full_path;
容易踩的坑：
- 字符串拼接必须显式转类型，
o.id::TEXT缺一不可，否则报错operator does not exist: text || integer - 如果表有触发器，UPDATE 可能被拦截；建议先
BEGIN; SET LOCAL session_replication_role = 'replica';临时禁用 - 递归深度无硬性上限，但若存在环（比如 A→B→A），会无限循环直到内存耗尽；务必提前用
SELECT * FROM orgs WHERE id = parent_id排查自环
跨数据库通用原则：别在递归逻辑里做业务判断
递归 CTE 只负责“把树按顺序拉出来”，更新动作和条件判断一定要后置。比如你想只更新“状态为启用”的节点路径，不要在 CTE 的递归部分加 WHERE status = 1，而应在 UPDATE 的 JOIN 条件或 WHERE 子句里过滤。
为什么？因为递归成员的 WHERE 是终止条件，不是数据筛选器——加错位置会导致子树断裂。例如：
- 错误写法：
SELECT ... FROM orgs o JOIN tree t ON o.parent_id = t.id WHERE o.status = 1→ 某个中间节点 disabled，整棵子树就断了 - 正确写法：
UPDATE orgs SET ... FROM tree WHERE orgs.id = tree.id AND orgs.status = 1→ 仅跳过更新，不影响路径生成
真正难处理的是父子关系脏数据：parent_id 指向不存在的 ID、循环引用、NULL 值混在中间层。这些不会让语法报错，但会让路径字段出现空值或重复片段——上线前务必用 SELECT 先跑一遍递归 CTE，人工扫几条关键路径确认逻辑是否符合预期。
