MySQL触发器禁止直接UPDATE、INSERT或DELETE自身所属表，因执行栈保护机制防止递归调用，报错ERROR 1442；绕过方法包括异步消息解耦、应用层统一处理或运行时标记跳过。
MySQL 触发器里 UPDATE 本表直接报错 ERROR 1442，不是锁问题，是执行栈保护
MySQL 根本不让你在触发器里 UPDATE、INSERT 或 DELETE 自己所属的表——哪怕只改一行，哪怕用 SET 代替整行更新，只要 SQL 语句目标是当前表，就会立刻中断并抛出：Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这不是事务隔离级别导致的，也不是表被锁住了，而是 MySQL 内部硬编码的执行栈拦截机制：防止触发器调用触发器再调用触发器，无限嵌套下去。
- 哪怕你把 UPDATE 封装进存储过程中，再从触发器里调用那个存储过程，照样报错
- 临时表、视图、JOIN 子查询中隐式更新本表，也全被拦住
-
RECURSIVE_TRIGGERS这个选项只存在于 SQL Server，MySQL 压根没有这个配置项
SQL Server 的 RECURSIVE_TRIGGERS 设置真能关掉递归？但多数场景不该开
SQL Server 确实提供服务器级开关：RECURSIVE_TRIGGERS，默认为 OFF（即禁止递归）。如果你看到两个表互相触发（比如 DNN_Roles 插入后调 aspnet_Roles_CreateRole，而后者又往 DNN_Roles 写），那大概率是两边都开了递归，或者没关干净。右键服务器 → 属性 → 高级 → “允许触发器激发其他触发器” 设为 False 可临时止血。
- 但这只是掩盖症状：真正的问题是设计上让两套权限系统强耦合在数据库层
- 开启递归后若没加深度限制（比如只允许最多 2 层）或短路条件（如仅当
salary != OLD.salary才执行），极易陷入不可控循环 - 跨库调用（如
OPENQUERY）、外部过程（如xp_cmdshell）在递归上下文中风险倍增，一并禁用更安全
绕过递归限制的三种可行路径：消息解耦、应用接管、标记跳过
想让“订单插入后自动同步更新部门父级名称”这类逻辑跑通，不能硬刚 MySQL 的限制，得换执行环境。
-
推荐：用异步消息解耦 —— 触发器里只写一条记录到
event_queue表或发 Kafka 消息，由独立消费者进程去执行后续UPDATE yckj_company，完全脱离触发器上下文 -
更可控：提到应用层统一处理 —— 把原来塞在触发器里的逻辑，挪到业务代码中，用一个事务包裹
INSERT orders+UPDATE yckj_company，既可保证一致性，又规避所有数据库层限制 -
慎用：运行时标记跳过 —— 在触发器开头加
IF @trigger_disabled IS NULL OR @trigger_disabled = 0 THEN ... END IF，并在应用层每次操作前设SET @trigger_disabled = 1；但所有入口必须严格一致，漏一个就可能引发数据不一致
别把触发器当业务逻辑胶水，它只适合做轻量校验和衍生写入
很多人试图用触发器替代应用逻辑，比如插入订单时调用邮件发送存储过程、跨库同步用户角色、根据多张表 JOIN 结果更新状态——这些都不是触发器该干的事。它本质是数据库的“钩子”，不是“工作流引擎”。
- 触发器中调外部服务（HTTP / SMTP / RPC）会把事务拖长，放大锁等待和超时风险
- 用
CHECK CONSTRAINT能实现的邮箱格式校验，比 BEFORE INSERT 触发器更高效、更透明 - 用
DEFAULT CURRENT_TIMESTAMP给创建时间赋值，比触发器里写SET NEW.create_time = NOW()更简洁、更少出错
真正容易被忽略的是：触发器错误不会在建的时候暴露，而是在第一次实际 DML 操作时才炸出来；且一旦涉及多表联动或跨版本迁移，它的行为极难预测和测试。
