mysql中update父节点时子树path无法在after update触发器内直接批量更新，因error 1442禁止修改同一表；应改用临时表中转或移至应用层事务处理。
MySQL中UPDATE父节点时，子树path字段无法批量更新？
直接在AFTER UPDATE触发器里写UPDATE tree SET path = ... WHERE path LIKE CONCAT(OLD.path, '%')会报错ERROR 1442。这不是语法或权限问题，而是MySQL事务隔离层面对同一张表的硬性禁止。
实操建议：
- 改用临时表中转：先INSERT INTO tmp_ids SELECT id FROM tree WHERE path LIKE CONCAT(OLD.path, '%')，再UPDATE tree JOIN tmp_ids ON tree.id = tmp_ids.id SET tree.path = ...
- 或封装成存储过程，触发器只调用它——但该存储过程内部仍不能直写UPDATE tree，必须保留临时表逻辑
- 更稳妥的做法是把路径更新移到应用层：监听parent_id变更后，由服务端发两条语句（改当前节点 + 批量改子树），用事务包住
PostgreSQL里递归更新子树路径是否可行？
PostgreSQL支持WITH RECURSIVE，但触发器内不能用CTE做UPDATE——触发器函数不允许执行修改目标表的递归语句，否则会引发不可预测的锁或死循环。
实操建议：
- 触发器只记录变更事件（如写入log表），另起一个异步job轮询log并执行递归UPDATE
- 若必须同步，用FOR EACH STATEMENT触发器调用外部函数，函数内用临时表+循环模拟递归，避免直接引用tree表
- 路径字段建议用TEXT类型而非VARCHAR(255)，避免拼接溢出；加显式长度校验，如IF LENGTH(NEW.path) > 512 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Path overflow'; END IF;
父子关系变更时，如何避免触发器漏更新子节点？
常见错误是只监听INSERT/UPDATE parent_id，却忽略UPDATE其他字段（如status、is_deleted）也可能影响层级可见性。只要业务上“该行参与层级计算”的条件变了，就得重新算子树。
实操建议：
- 触发器事件要写全：AFTER INSERT OR UPDATE OF parent_id, status, is_deleted OR DELETE
- UPDATE逻辑必须判断OLD和NEW是否真有差异：IF OLD.parent_id != NEW.parent_id OR OLD.status != NEW.status THEN ...
- 软删除场景下，DELETE触发器不生效，得靠UPDATE status = 'deleted'触发，且子树更新逻辑要兼容status过滤
path字段用UUID还是自增ID更稳妥？
UUID作为path组件极易爆长：单个UUID占36字符，三层嵌套就超100字符，加上分隔符和深度预留，VARCHAR(255)很快不够用。而自增ID平均仅占5–8字符，空间友好得多。
实操建议：
- 优先用BIGINT自增ID，配合映射表处理迁移或合并场景
- 若需全局唯一，可用base32编码压缩ID（如123456789 → '3nq9v'），长度可控
- 绝对避免在path里拼接JSON、HTML或用户输入内容——这些字段一旦含特殊字符或空格，会破坏路径解析逻辑
path字段变更后，下游依赖它的查询（如WHERE path LIKE '1/12/%'）和索引有效性必须同步验证。很多线上问题不是触发器没跑，而是索引没重建或LIKE前缀不匹配新格式。
