直接在触发器里UPDATE自己监听的表必然出问题：MySQL报ERROR 1442硬拦截，SQL Server静默递归致卡死，PostgreSQL默认放行但需pg_trigger_depth()>1手动截断；数据库级开关如RECURSIVE_TRIGGERS对自引用无效，唯一可靠解法是运行时标记（如CONTEXT_INFO）或深度控制。
直接在触发器里 UPDATE 自己监听的表，一定会出问题——MySQL 立即报 ERROR 1442，SQL Server 静默递归卡死，PostgreSQL 默认放行但必须手动截断。靠数据库开关（如 RECURSIVE_TRIGGERS）基本无效，唯一能落地的解法是运行时标记或深度控制。
MySQL 触发器里 UPDATE 同一张表会直接报错
这不是性能或并发问题，而是 MySQL 解析阶段的硬拦截：只要触发器体中出现对当前表的 UPDATE、INSERT 或 DELETE，不管 WHERE 条件多精确，都会抛出 ERROR 1442。
-
BEFORE触发器中用SET NEW.col = ...是安全的，它只修改即将写入的值，不触发新事件 -
AFTER触发器中任何 DML 操作（哪怕UPDATE t SET updated_at = NOW() WHERE id = NEW.id）都会被拦 - 跨库操作（如
UPDATE other_db.users）如果目标表也有触发器，照样触发ERROR 1442 - 别指望
max_sp_recursion_depth绕过限制——它只影响存储过程，对触发器无效
SQL Server 必须用 CONTEXT_INFO 做会话级标记
RECURSIVE_TRIGGERS OFF 对自引用（A → A）完全无效，@@NESTLEVEL 在并行执行或视图触发路径下行为不稳定，真正轻量、隔离、无需建表的方案是 CONTEXT_INFO。
- 业务 SQL 执行前设标记：
SET CONTEXT_INFO 0x54524947474552（即 "TRIGGER" 的 ASCII 十六进制） - 触发器开头第一行就检查：
IF CONTEXT_INFO() = 0x54524947474552 RETURN - 避免用
CONVERT(VARCHAR, CONTEXT_INFO())比较——编码或空字节会导致截断失效 - 若触发器由存储过程调用，过程开头设标记、结尾清空：
SET CONTEXT_INFO 0x0
PostgreSQL 要靠 pg_trigger_depth() 主动截断
PostgreSQL 不禁止自更新，但每次都会再触发，所以必须自己判断层级。它提供精准函数，但容易漏掉 TG_OP 组合校验。
- 触发器开头加：
IF pg_trigger_depth() > 1 THEN RETURN; END IF; - 更精细控制可结合：
IF pg_trigger_depth() > 1 AND TG_OP = 'UPDATE' THEN RETURN; -
pg_trigger_depth()返回的是当前触发器嵌套层数，首次为 1，第二次为 2，以此类推 - 注意：如果触发器调用了函数，而函数里又间接更新了本表，仍可能绕过该判断
最容易被忽略的是：所有 DML 必须走唯一索引，禁止 WHERE status = 'pending' 这类范围条件——它会触发 gap lock，让多个并发事务在相同间隙上反复争抢；另外，调试时别依赖日志表写入是否成功，先确认 log_warnings = 2 和 log_error 路径是否可写。
