MySQL触发器中禁止对本表执行DML操作，否则报ERROR 1442；BEFORE中应使用SET NEW.xxx修改数据，AFTER中不可操作本表；需通过中间表+异步消费实现间接更新。
这个报错不是死循环，是 MySQL 硬性拦截——只要触发器里出现对本表的 UPDATE、INSERT 或 DELETE，立刻中断并抛出 ERROR 1442。 它不看你有没有加 WHERE、是不是只改一行、有没有事务包装，也不管你调用的是存储过程还是直接写 SQL。本质是执行栈保护机制，防递归，不是锁或并发问题。
BEFORE 触发器里该用 SET NEW.col，别写 UPDATE
如果你只是想修改即将插入或更新的那行数据（比如补时间戳、清洗字段、设默认状态），BEFORE INSERT 或 BEFORE UPDATE 中必须用 SET NEW.xxx = ...，而不是再发一条 UPDATE 语句。
-
SET NEW.created_at = NOW();✅ 正确：改的是“待插入/待更新”的内存副本 -
UPDATE users SET status = 'pending' WHERE id = NEW.id;❌ 报错：触犯ERROR 1442，哪怕表名写全、加了索引也没用 - 注意：
NEW在AFTER触发器中只读，不能赋值；所以这类逻辑只能放在BEFORE阶段
AFTER 触发器里禁止任何本表 DML 操作
AFTER 类型触发器没有 NEW 可写，但很多人误以为“既然已提交，就能安全 UPDATE”，结果一写就崩。MySQL 不区分“刚提交”还是“正在执行”，只要语句目标表和触发源表相同，一律拒绝。
-
AFTER INSERT ON kaoqinjilu里执行UPDATE kaoqinjilu SET processed = 1 WHERE id = NEW.id;→ 必报ERROR 1442 - 跨库也不行：
UPDATE other_db.kaoqinjilu ...同样被拦——判断依据是表名，不是库名 - 连间接调用都无效：把
UPDATE封进存储过程，再从触发器里CALL sp_update_self()，照样报错
真要落库？走中间表 + 异步消费
如果业务强依赖“触发后必须同步更新本表某字段”（比如插入考勤记录后立刻标记为已处理），唯一合规路径是解耦：触发器只写中间表，由外部机制回填。
- 建一张轻量日志表：
CREATE TABLE kaoqinjilu_queue (id BIGINT AUTO_INCREMENT PRIMARY KEY, uid INT, action VARCHAR(20), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 触发器只做插入：
INSERT INTO kaoqinjilu_queue (uid, action) VALUES (NEW.uid, 'mark_processed'); - 用 MySQL 事件调度器（
EVENT）或应用层定时任务消费这张表，执行真正的UPDATE kaoqinjilu，并删队列记录 - 注意权限：事件或外部脚本需有目标表的
UPDATE权限，且不能依赖触发器上下文（如NEW在事件里不可用）
容易忽略的边界点
很多人试过“用临时表绕过”，比如 CREATE TEMPORARY TABLE tmp AS SELECT ... FROM kaoqinjilu 再更新，但这是徒劳的——TEMPORARY TABLE 只是会话级别别名，底层仍指向原表结构，MySQL 仍视为同一对象。
- 真正能绕开的只有三类操作：
SET NEW.xxx、向其他表INSERT/UPDATE、写日志表 - 错误日志里看到
Can't update table 'kaoqinjilu'...时，别查锁或事务隔离级别，直接搜触发器代码里的UPDATE/INSERT/DELETE关键字 - 调试建议：把触发器逻辑先封装成存储过程，手动传参测试，避免每次 INSERT 都触发失败打断流程
