ERROR 1442 是 MySQL 禁止触发器自引用修改的明确报错，本质是语法级拦截而非死循环；须避免在触发器中直接操作原表，改用 SET NEW.col 赋值、中间表解耦或严格校验调用链。
触发器一改自己监听的表就报 ERROR 1442
这是 MySQL 触发器死循环最典型的症状，不是真“卡住”，而是直接被数据库拦下来：ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。它说明你正在一个 AFTER UPDATE 或 BEFORE INSERT 里，又对同一张表执行了 UPDATE、INSERT 或 DELETE —— MySQL 明确禁止这种自引用修改。
- 别试图在触发器里写
UPDATE users SET status = 'processed' WHERE id = NEW.id（哪怕加了WHERE条件） -
BEFORE类型里应优先用SET NEW.col = ...修改即将插入/更新的值，而不是再发一条 SQL - 如果逻辑必须落库（比如要记日志+同步状态），拆成两步：先写入一张中间表（如
trigger_queue），再由事件调度器或外部脚本消费
为什么加了 IF OLD.status != NEW.status 还会循环？
条件判断只是第一道防线，但不等于万能保险。很多看似“安全”的写法，实际仍可能触发递归——比如触发器里调用了某个存储函数，而该函数内部悄悄执行了对原表的 UPDATE；或者你在触发器中用了 INSERT INTO other_db.users，但 other_db.users 上恰好也有个同名触发器，又反向操作了当前库的表。
- 检查所有被触发器直接或间接调用的函数、视图、事件，确认它们没碰原表
- 跨库操作不等于“解耦”，只要最终链路回到同一张表，仍算循环
-
max_sp_recursion_depth是兜底参数，设成1可强制暴露问题，但不能替代逻辑修正
调试时往日志表 INSERT 为什么没反应？
因为触发器失败常常是静默的：SQL 语句本身成功了（比如 INSERT 成功），但触发器中途退出，且没报错——尤其当 sql_mode 里没开 STRICT_TRANS_TABLES 时，空值赋给非空字段、除零等都可能被忽略。
- 务必确认
log_error路径（查SHOW VARIABLES LIKE 'log_error'），并确保log_warnings = 2 - 调试用的日志表必须和触发目标表完全无关（别叫
users_log如果主表是users） - 用
DECLARE CONTINUE HANDLER捕获异常 +SIGNAL主动抛错，比靠日志更可靠
线上已跑出死循环，怎么紧急止损？
所谓“死循环”在 MySQL 里极少真正无限跑，多数是触发器反复报错、事务卡住、连接堆积。此时不要猜，先看真实现场：
- 运行
SHOW PROCESSLIST，找State长时间停在Updating或Waiting for table metadata lock的线程 - 查
SELECT * FROM information_schema.INNODB_TRX，看有没有长时间未提交的事务锁着表 - 用
KILL [id]干掉可疑线程后，立刻禁用触发器：ALTER TABLE tbl_name DISABLE TRIGGER trigger_name
修复逻辑前，千万别只改代码再 ENABLE —— 先在测试库用真实数据流完整走一遍，否则下次出问题还是深夜三点。
