MySQL中UPDATE不能直接引用目标表，会报ERROR 1093；须用派生表（如JOIN子查询加AS别名）或CTE绕过，PostgreSQL支持UPDATE FROM但需防自环与悬空引用。
UPDATE语句中不能直接引用目标表作子查询
想用 UPDATE t SET parent_id = (SELECT id FROM t WHERE ...) 这种写法会报错，MySQL 报 ERROR 1093: You can't specify target table 't' for update in FROM clause，PostgreSQL 则可能提示 relation "t" is not allowed in this context。这不是语法疏忽，而是引擎为避免更新过程中的读写冲突做的硬性限制。
- 必须把子查询结果“绕开”目标表：用派生表（即嵌套一层
SELECT）、临时表或 CTE（PostgreSQL / SQL Server / MySQL 8.0+） - MySQL 5.7 及更早版本不支持 CTE，只能靠派生表；MySQL 8.0+ 推荐用
WITH提升可读性 - 注意层级深度——若要批量修正整棵树的
parent_id，单条UPDATE无法递归处理，得配合循环或应用层逻辑
用派生表安全更新父节点ID（兼容 MySQL 5.7+）
核心是把原表查出的数据先装进一个匿名派生表，再拿它去更新原表。比如要把所有 level = 3 的节点，其 parent_id 改成同名但 level = 2 节点的 id：
UPDATE nodes AS n JOIN ( SELECT id, name FROM nodes WHERE level = 2 ) AS p ON n.parent_name = p.name SET n.parent_id = p.id WHERE n.level = 3;
-
JOIN比子查询更直观，也更容易加条件过滤 - 确保关联字段（如
parent_name和name）有索引，否则大表上性能极差 - 务必加上
WHERE限定更新范围，漏加可能导致全表误更新
用CTE逐层修正（PostgreSQL / MySQL 8.0+）
如果父节点本身也在被更新的范围内（比如重建整棵树的父子关系），CTE 更适合表达层级依赖。例如将所有 path 字段形如 /a/b/c/ 的节点，按路径层级自动设置 parent_id：
WITH RECURSIVE tree AS ( SELECT id, name, split_part(path, '/', 2) AS parent_path, level FROM nodes WHERE level > 1 ) UPDATE nodes n SET parent_id = t.id FROM tree t JOIN nodes p ON p.name = t.parent_path AND p.level = t.level - 1 WHERE n.id = t.id;
- PostgreSQL 中
split_part是示例函数，实际需根据你的路径分隔方式调整（如用substring_index或正则） - MySQL 8.0+ 的 CTE 不支持在
UPDATE的FROM子句中直接引用，得改用JOIN+ CTE 衍生表形式 - CTE 本身不存储数据，每次执行都重算，深层递归时注意
max_recursion_depth限制
更新前必须验证父子闭环与空值风险
自关联表最常踩的坑不是语法，而是业务逻辑崩坏：把某个节点设成自己的父节点、让根节点的 parent_id 指向不存在的 ID、或意外清空 parent_id 导致树断裂。
- 执行前先跑一遍检查语句：
SELECT * FROM nodes WHERE id = parent_id（自环）、SELECT * FROM nodes WHERE parent_id NOT IN (SELECT id FROM nodes) AND parent_id IS NOT NULL（悬空父引用） - 对
parent_id字段加外键约束（FOREIGN KEY (parent_id) REFERENCES nodes(id) ON DELETE SET NULL）能防一部分问题，但无法阻止自环 - 涉及大量更新时，务必在事务里操作，并提前备份关键字段（如用
SELECT id, parent_id INTO TEMP TABLE nodes_backup FROM nodes）
真正麻烦的从来不是怎么写那条 UPDATE，而是确认你改的每一行，都在维持一棵合法、无环、可遍历的树。
