路径字段需用ifnull安全拼接，如concat(ifnull(parent.path, ''), '/', new.id)；insert前须查父节点path并校验存在；update时需同步修正path且拦截手动修改；delete应避免触发器递归，推荐应用层按path前缀清理。
触发器里怎么拼出正确的路径值
路径字段（比如 path）本质是字符串拼接，不是计算字段。父级的 path 值必须已存在且非空，否则新插入的子节点会得到 NULL 或错误前缀。常见错误是直接写 CONCAT(parent.path, '/', NEW.id)，但没检查 parent.path 是否为 NULL，导致整条路径变 NULL。
实操建议：
- 用
IFNULL(parent.path, '')安全兜底，再手动补分隔符，比如CONCAT(IFNULL(parent.path, ''), '/', NEW.id) - 如果根节点路径要以
/开头（如/1/2/5），则统一在拼接前加前导斜杠：CONCAT('/', IFNULL(parent.path, ''), '/', NEW.id)，并确保根节点自身path = '/1' - 避免在触发器里查多层祖先——只依赖直接父节点的
path，否则嵌套查询易锁表、性能差
INSERT 触发器必须查父节点，不能只靠 NEW.parent_id
NEW.parent_id 是数值，不等于路径。你得用它去查父记录的 path 字段，否则没法拼。但这里容易踩两个坑：父记录可能还没提交（在事务中）、或父记录根本不存在（外键未约束或被绕过）。
实操建议：
- 用
SELECT path INTO @parent_path FROM tree_table WHERE id = NEW.parent_id，然后判断@parent_path是否为NULL；若为空，应SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Parent not found'中断插入 - 不要用
JOIN或子查询直接嵌在SET里，MySQL 触发器对复杂查询支持弱，易报错Can't update table 'tree_table' in stored function/trigger - 确保父节点表有
id上的索引，否则每次插入都全表扫描
UPDATE 触发器要同时处理 parent_id 和 path 变更
用户改了 parent_id，路径就得重算；但用户也可能直接改 path 字段（绕过逻辑），这时你要拦截。最危险的是：只更新了 parent_id 却没更新 path，导致数据不一致。
实操建议：
- 在
BEFORE UPDATE里判断OLD.parent_id != NEW.parent_id，成立则重新查父节点拼路径；否则保留原path - 加一层防护：如果
NEW.path != OLD.path AND NEW.parent_id = OLD.parent_id，说明用户手动改了path，此时应SIGNAL拒绝，强制走层级逻辑 - 注意：MySQL 触发器无法在
UPDATE中修改NEW.path后再让其他触发器响应，所以所有路径修正必须在同一个BEFORE UPDATE里做完
DELETE 触发器不能只删当前行，要考虑子树级联
删一个节点，它的所有后代 path 并不会自动失效，但业务上它们已成孤儿。你有两个选择：物理删除整棵子树，或标记逻辑删除。触发器本身不能递归删子节点（MySQL 不允许触发器改同表），所以必须靠应用层或存储过程配合。
实操建议：
- 在
BEFORE DELETE里不做实际删除，只SIGNAL提示“请使用存储过程删除子树”，避免静默残留 - 如果坚持用触发器清理，需改用
AFTER DELETE+ 调用存储过程，但该存储过程必须用循环或临时表逐层删，且要处理自增 ID 冲突风险 - 更稳妥的做法是：禁止直接
DELETE，全部走带路径前缀匹配的语句，例如DELETE FROM tree_table WHERE path LIKE CONCAT(OLD.path, '/%')，这句必须由应用或存储过程执行，不在触发器里
路径字段的维护关键不在语法多炫，而在于每一步都预判了父值是否存在、事务是否可见、以及人为绕过逻辑的可能性。一旦漏掉 IFNULL 或忘了 SIGNAL 校验，后面查出来的树就全是断裂的。
