update父子路径未更新的主因是触发器中仅修改new.path而未递归更新后代path，且after触发器中直接update同表会报错，需用临时表或存储过程中转，并同步维护level等衍生字段。
UPDATE 时父子路径没更新，触发器里忘改 NEW.path
递归结构（比如组织架构、分类树）常靠 path 字段（如 '/1/5/23/'）加速查询，但 UPDATE 父节点 name 或移动节点位置时，子树的 path 不会自动变——触发器必须显式重算。常见错误是只更新当前行的 NEW.path，却没递归更新所有后代。
实操建议：
- 触发器类型必须是
AFTER UPDATE，不能用BEFORE：因为要读取旧path做匹配，还要写后代，BEFORE阶段无法安全修改其他行 - 用
UPDATE ... WHERE path LIKE CONCAT(OLD.path, '%')批量更新整棵子树，别用循环逐条查 - 注意
OLD.path和NEW.path的差异类型：如果只是改名，OLD.path = NEW.path，此时不用动子树；如果是parent_id变了，才需要重构路径 - MySQL 8.0+ 可用 CTE 写递归 UPDATE，但多数老版本得靠自连接或存储过程——别硬套新语法
触发器里执行 UPDATE 报错 Can't update table 'xxx' in stored function/trigger
这是 MySQL 经典限制：触发器中不能直接 UPDATE 触发它的同一张表。你写了个 AFTER UPDATE ON tree，又在触发器里 UPDATE tree，MySQL 直接拒绝。
实操建议：
- 绕过方法：用临时表中转。先
INSERT INTO tmp_tree SELECT id FROM tree WHERE path LIKE CONCAT(OLD.path, '%')，再UPDATE tree JOIN tmp_tree ON tree.id = tmp_tree.id SET tree.path = ... - 更稳妥的做法是把更新逻辑抽到存储过程里，触发器只调用它——但要注意存储过程里也不能直接 UPDATE 同表，仍需中转
- PostgreSQL 没这限制，
UPDATE自己的表没问题，但要注意事务可见性：刚改完的行在后续UPDATE中是否可见，得看READ COMMITTED还是REPEATABLE READ
路径字段长度不够，UPDATE 子树时爆 Data too long for column 'path'
path 字段通常定义为 VARCHAR(255)，但深度大、ID 长的树（比如 ID 是 UUID 或带前缀的字符串），拼起来轻松超长。触发器一跑批量 UPDATE，就卡在截断报错。
实操建议：
- 建表时别拍脑袋定
VARCHAR(255)，按最大可能深度预估：比如最多 10 层，ID 平均 12 字符，加上斜杠，至少留VARCHAR(200)—— 但更推荐VARCHAR(512)或TEXT（MySQL TEXT 支持索引前缀） - 触发器里做长度校验：
IF LENGTH(CONCAT(NEW.path, child_id, '/')) > 512 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Path overflow'; END IF; - 别依赖
MAX(id)推深度——实际业务中节点可能被删，ID 不连续，真正瓶颈是运营人员手动拖拽导致的意外深度
移动节点后子树路径正确，但父级计数器（如 children_count）没同步
很多业务除了 path，还维护 children_count 或 level 字段用于快速统计或前端渲染。触发器只修 path，这些衍生字段就掉队了，查出来数据对不上。
实操建议：
- 在同一个触发器里顺手更新：
UPDATE tree SET level = LENGTH(path) - LENGTH(REPLACE(path, '/', '')) - 1 WHERE path LIKE CONCAT(NEW.path, '%'); -
children_count更麻烦：得先清空原父节点和新父节点的计数，再重新聚合。建议用单独的维护任务（比如每晚定时 job），而不是全压给触发器——否则每次拖一个节点，就要扫两次全树 - 如果用了物化路径 + 闭包表双模型，触发器必须同时更新两张表，且保证原子性：要么都成功，要么都失败，用事务包裹，别让闭包表和主表状态不一致
路径更新看着是字符串拼接，实际牵扯锁粒度、触发时机、字段协同——最易忽略的是：你以为只改了一行，触发器却悄悄锁住了整个子树，高并发下容易成瓶颈。
