mysql触发器中直接update/insert/delete当前表会立即报error 1442，因语法解析阶段即拦截；唯一安全方式是在before insert/update中用set new.column修改行副本，after中任何dml均禁止。
MySQL 触发器里一写 UPDATE、INSERT 或 DELETE 当前表，立刻报 ERROR 1442，这不是运行时卡死，而是语法解析阶段就被拦截——根本没机会执行到“循环”那步。
BEFORE 触发器中改本行数据，只用 SET NEW.xxx
这是唯一安全、同步、零风险的方式。你不是在“更新表”，而是在“修正即将插入或修改的那行数据”。MySQL 允许在 BEFORE INSERT 和 BEFORE UPDATE 中写入 NEW 字段，且不会触发新事件。
-
NEW在BEFORE中可写，在AFTER中只读；写错时机（比如放到AFTER里）会直接报错或静默失败 - 字段类型必须兼容：给
NEW.status赋值'done'前，确认status是VARCHAR或允许字符串的类型 - 不能在
BEFORE里再调用含本表 DML 的存储过程——哪怕只是CALL update_log_table(NEW.id)，只要它内部有UPDATE，照样触发ERROR 1442 - 若需从其他表查值（如根据
user_id查role_name），可用SELECT ... INTO @var FROM other_table WHERE id = NEW.user_id，再赋给NEW.role_name
AFTER 触发器中要改本表？必须解耦到外部
AFTER 类型下任何对当前表的 DML 都被禁止，强行写 UPDATE t SET x = y WHERE id = NEW.id 就是标准报错现场。这时候没有“绕过技巧”，只有移出触发器上下文。
- 推荐用中间表 + 事件调度器：触发器里只写
INSERT INTO trigger_queue (table_name, row_id, action) VALUES ('users', NEW.id, 'sync')，再由EVENT每秒拉取并执行真实更新 - 更彻底的解法是应用层接管：把原本塞在触发器里的逻辑（如“订单插入后更新库存”）挪到业务代码中，用单事务包裹
INSERT orders+UPDATE inventory - 不建议用
INSERT DELAYED（已弃用）或SET SQL_LOG_BIN = 0（不影响该限制，只关 binlog） - 跨库操作也不保险：在
db1.t1的触发器里UPDATE db2.t2，只要db2.t2上也有触发器且反向操作db1.t1，照样递归
调试时发现触发器“没反应”？先查日志和会话变量
触发器失败常常是静默的：SQL 成功了，但触发器中途退出，没报错也没效果。尤其当 sql_mode 没开 STRICT_TRANS_TABLES 时，空值赋给非空字段、除零等都会被忽略。
- 确认
log_error路径：SHOW VARIABLES LIKE 'log_error'，并确保log_warnings = 2 - 日志表名必须和主表完全无关（别叫
users_log如果主表是users），否则可能被同一套触发器链影响 - 用
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION捕获异常，再SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'trigger failed'主动抛错，比依赖日志更可靠 - 连接池场景（如
pymysql）下，max_sp_recursion_depth和@TRIGGER_DISABLED必须每次获取连接后重置，否则复用旧连接会失效
真正容易被忽略的是：所有被触发器间接调用的函数、视图、存储过程，只要里面碰了本表，就等于在触发器里碰了本表。检查链路比加 IF 判断更重要。
