MySQL触发器中禁止直接UPDATE同一张表，因事务隔离设计会引发锁与一致性风险，错误码1442；需用临时表、存储过程或应用层处理，并注意path字段长度及OLD/NEW路径是否真实变更。
MySQL 触发器里不能直接 UPDATE 同一张表，这是硬限制，不是配置问题，也不是版本低——所有 MySQL 版本都这样。
触发器中执行 UPDATE tree 报错 Can't update table 'tree' in stored function/trigger
这是 MySQL 的底层事务隔离设计决定的：AFTER UPDATE 触发器刚读完旧数据，还没提交，此时再对同一张表发起 UPDATE，会引发不可预测的锁和一致性风险，所以直接拒绝。你查 SHOW ERRORS 看到的错误码通常是 ERROR 1442。
常见误操作：
- 在
AFTER UPDATE ON tree里写UPDATE tree SET path = ... WHERE path LIKE CONCAT(OLD.path, '%') - 试图用
BEFORE UPDATE提前改子树路径——但OLD.path还没变，NEW.path又不能用于匹配后代，逻辑就断了
实操建议：
- 用临时表中转：先
CREATE TEMPORARY TABLE tmp_ids AS 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，必须保留临时表或用INSERT ... SELECT+REPLACE INTO模拟更新 - 如果业务允许，把路径维护移到应用层：监听 parent_id 变更后，由服务端发两条语句——一条改当前节点，一条批量改子树（用事务包住）
path 字段爆 Data too long for column 'path'
字段定义为 VARCHAR(255) 是很多人的默认选择，但拼接路径如 '1/12/123/1234/12345/...' 在 ID 是 bigint 或带业务前缀时，10 层就轻松超长。触发器一跑批量更新，整棵子树卡在截断报错，且 MySQL 默认静默截断不报错，除非开了 STRICT_TRANS_TABLES。
实操建议：
- 建表时按最大可能深度估算长度：比如最多 12 层、ID 平均占 15 字符、每层加 1 个斜杠，至少预留
VARCHAR(200)——但更稳妥是直接上VARCHAR(512)或TEXT（MySQL 8.0+ 支持TEXT列加前缀索引） - 在触发器里加显式校验：
IF LENGTH(CONCAT(NEW.path, '/', child_id)) > 512 THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Path overflow'; END IF; - 避免用 UUID 做 path 组件：UUID 占 36 字符，三层就吃掉 100+ 字符。可考虑用自增 ID + 映射表，或用 base32 编码压缩
MySQL 8.0+ 的 CTE 递归 UPDATE 不适用于触发器场景
WITH RECURSIVE 能写递归查询，但 MySQL 不支持递归 UPDATE 语法。你查文档看到的“MySQL 支持递归 CTE”，仅指 SELECT，不包括 UPDATE、DELETE 或 INSERT ... SELECT 中的递归子句。
常见误解：
- 以为
UPDATE tree SET path = ... FROM (WITH RECURSIVE ...)能跑通——实际报错ERROR 1288或语法错误 - 在触发器里嵌套 CTE 查询结果再 UPDATE——依然撞上同表限制，只是绕了个弯而已
实操建议：
- CTE 只用于查询（比如前端拉取完整树）、校验（比如检查移动后是否成环）、或导出快照，别指望它替代路径更新逻辑
- 真要靠数据库自动维护，闭包表（
area_path）比路径字符串更可靠：插入时用触发器往area_path插三元组，查子树直接SELECT descendant FROM area_path WHERE ancestor = ?，无长度焦虑、无递归限制、索引友好 - 若坚持用路径字段，老老实实用自连接模拟递归：比如先
UPDATE t1 JOIN t2 ON t1.parent_id = t2.id SET t1.path = CONCAT(t2.path, '/', t1.id)，分多轮跑，但得控制好 depth 条件防止无限循环
最常被忽略的一点：触发器里的 OLD.path 和 NEW.path 是否真的变了，决定了要不要动子树。只改名字（name 字段）但 parent_id 没变，OLD.path = NEW.path，这时候连临时表都不用建。很多人一上来就全量扫子树，白白拖慢主更新。判断逻辑必须放在触发器开头，而不是塞在 UPDATE 语句里靠 WHERE 过滤。
