MySQL触发器能维护树形路径，但必须用BEFORE INSERT和BEFORE UPDATE，通过IFNULL安全拼接、查父节点校验、拦截手动改path，且不可递归触发，否则报“Can't update table”错误。
直接说结论：MySQL 触发器能维护树形路径，但必须用 BEFORE INSERT 和 BEFORE UPDATE，靠 IFNULL 拼接、查父节点校验、拦截手动改 path，且不能依赖递归触发——否则必报 Can't update table 'xxx' in stored function/trigger。
拼接 path 时为什么 CONCAT(parent.path, '/', NEW.id) 会出错
因为 parent.path 是 NULL 时，整个 CONCAT 结果就是 NULL，新记录的 path 就废了。这不是语法错误，是逻辑断链。
- 必须用
CONCAT(IFNULL(parent.path, ''), '/', NEW.id)兜底，让根节点（parent_id IS NULL）得到'/1'而不是NULL - 如果业务要求路径以斜杠开头结尾（如
/1/5/23/），统一写成CONCAT('/', IFNULL(parent.path, ''), '/', NEW.id, '/') -
COALESCE在 MySQL 中和IFNULL行为一致，但IFNULL更简洁，且只接受两个参数，语义更明确
INSERT 触发器里怎么安全查父节点
你不能只信 NEW.parent_id，它只是个数字；你得查出对应记录的 path 值才能拼。但查的时候有两层风险：父记录还没提交（事务隔离）、或根本不存在（外键没建或被绕过）。
- 用
SELECT path INTO @parent_path FROM tree_table WHERE id = NEW.parent_id;，再判断@parent_path IS NULL - 若为空，必须
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Parent not found';中断插入，不能默认填空字符串 - 别在
SET里直接嵌子查询，比如SET NEW.path = (SELECT CONCAT(...) FROM ...)，MySQL 触发器对这种写法支持差，容易报错 - 确保
tree_table.id有主键、parent_id有索引（KEY idx_parent_id (parent_id)），否则每次插入都全表扫描
UPDATE 触发器如何防 path 和 parent_id 不一致
用户可能只改 parent_id 忘了改 path，也可能直接手改 path 绕过层级逻辑——这两种都会导致数据不一致，且很难事后发现。
- 在
BEFORE UPDATE里先判断：IF OLD.parent_id != NEW.parent_id THEN ... 重新拼 path ... END IF; - 再加一层防护：
IF NEW.path != OLD.path AND NEW.parent_id = OLD.parent_id THEN SIGNAL ... 'Manual path edit disallowed'; END IF; - 所有路径计算必须在同一个触发器里做完，MySQL 不支持触发器中修改
NEW.path后再触发另一个触发器响应 - 注意：触发器只能修当前行的
path，不会自动更新子树。深层变更后需应用层或定时任务跑一次修正
DELETE 为什么不能靠触发器级联清理子树
触发器里执行 DELETE FROM tree_table WHERE path LIKE CONCAT(OLD.path, '%') 看似合理，但会立即报错 Can't update table 'tree_table' in stored function/trigger——因为 DELETE 正在执行，表已被锁定，不能再被同个触发器修改。
- MySQL 触发器禁止在触发过程中修改自身表（即使是不同行），这是硬限制，不是配置能调的
- 真正可行的做法是：应用层按
OLD.path前缀查出所有后代 ID，再分批 DELETE；或用临时表暂存待删 ID，由外部作业处理 - 如果业务允许，把删除逻辑下沉到存储过程里，用循环 +
MAX_DELETES控制单次删多少，避免锁表太久
最常被忽略的一点：路径字段不是“算出来就行”，而是要和业务读取逻辑严格对齐。比如前端用 path LIKE '/1/%' 查子树，那后端拼接时就必须保证所有 path 都带前导斜杠、结尾不带斜杠（或都带），否则 LIKE 会漏数据。这个细节不在触发器里体现，但在设计之初就得定死。
