error 1442是mysql语法级硬拦截，非死循环结果；after update中任何对本表的update/insert/delete均被立即拒绝，无论条件、封装或跨库操作，唯一安全修改方式是before中set new或改用中间表+外部消费。
为什么AFTER UPDATE触发器一写UPDATE就报ERROR 1442
MySQL在解析触发器体时，只要发现任何对当前表的UPDATE、INSERT或DELETE语句，立刻拒绝执行并抛出ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger。这不是死循环发生后的报错，而是语法层硬拦截——哪怕你加了WHERE id = NEW.id、IF OLD.status != NEW.status，甚至把UPDATE封装进存储过程里调用，照样报错。
AFTER中真要改本表数据，只能换路子
不能直接UPDATE，不等于不能达成目的。关键是要把“写操作”从触发器上下文中移出去：
- 用中间表暂存动作：在触发器里只做
INSERT INTO trigger_queue (table_name, pk, action, new_status) VALUES ('orders', NEW.id, 'update_status', NEW.status) - 由外部机制消费：比如用
EVENT每秒轮询trigger_queue并批量执行真实UPDATE；或业务应用监听消息队列（如Redis Stream），收到记录后主动更新 - 避免用会话变量
@skip_my_trigger跳过——它必须手动在业务SQL前SET @skip_my_trigger := 1，且后续同连接所有语句都会被跳过，极易误伤
跨库UPDATE也可能触发ERROR 1442
你以为UPDATE db2.users SET updated_at = NOW() WHERE id = NEW.user_id就安全？不一定。如果db2.users上也有触发器，且它又反向UPDATE orders，那整个链路仍会被MySQL判定为“递归使用同一张表”，最终在db2.users触发器里报同样的ERROR 1442。
- 检查所有被UPDATE的目标表，确认其上无反向操作原表的触发器
- 跨库操作不是免检通道，只是把风险转移到了另一张表的触发器里
- 用
SHOW TRIGGERS FROM db2快速扫一遍目标库的触发器定义
BEFORE UPDATE比AFTER更安全，但别乱用
BEFORE UPDATE里允许SET NEW.col = ...，这是唯一能“修改本表语义”且不触发新事件的位置。但它只适用于字段值修正类场景，比如自动填充updated_at、标准化email格式、校验状态流转合法性。
- 不要在
BEFORE UPDATE里调用含DML的存储过程——即使过程不显式写当前表名，只要路径中可能间接UPDATE，仍会触发ERROR 1442 - 别指望
BEFORE能替代AFTER的所有用途：比如你要根据新订单生成库存流水，就不能靠SET NEW搞定，必须拆到外部 -
max_sp_recursion_depth设成1只是让错误更快暴露，不是解法；它不能绕过限制，反而可能掩盖设计缺陷
