报错本质是各数据库对触发器调用链的不同限制机制：mysql语法拦截同表更新，sql server硬限32层栈深，postgresql依赖pg_trigger_depth()检测，oracle统一限制50层递归sql。
报错不是因为“嵌套层级没设对”，而是数据库在运行时检测到触发器调用链形成了闭环或越界——MySQL直接禁止、SQL Server卡在32层、PostgreSQL等栈溢出才拦、Oracle硬限50层。改配置参数不能解决根本问题，得从触发器逻辑本身下手。
MySQL 报 ERROR 1442：根本不是递归，是语法拦截
你在 AFTER UPDATE 里写 UPDATE users SET status = 'done' WHERE id = NEW.id，MySQL 立刻抛 ERROR 1442: Can't update table 'users' in stored function/trigger...。这不是递归深度超了，是它压根不让你碰本表。
-
max_sp_recursion_depth对触发器完全无效，别去调 -
BEFORE触发器应优先用SET NEW.status = 'done'修改值，而不是发新 SQL - 真要落库（比如记日志+同步状态），必须走中间表：
INSERT INTO users_trigger_queue (user_id, action) - 临时表、视图、子查询里隐式更新本表，照样被拦
SQL Server 报 “Maximum nesting level exceeded”：32 层是硬限制
它允许你在 AFTER UPDATE 里直接 UPDATE orders SET updated_at = GETDATE()，但会再次触发自身，形成无限递归。表现常为连接卡死、sp_who2 显示 LCK_M_U，或最终爆栈。
- 只关
RECURSIVE_TRIGGERS不够，必须同时执行：ALTER DATABASE [db] SET RECURSIVE_TRIGGERS OFF+EXEC sp_configure 'nested triggers', 0; RECONFIGURE -
@@NESTLEVEL是动态值，主语句为 1，每进一层触发器/存储过程/UDF 都 +1；但别用它做控制依据——CLR 调用、sp_executesql也占层，不可预测 - 更可靠的是在触发器开头加守卫：
IF TRIGGER_NESTLEVEL() > 1 RETURN，或用CONTEXT_INFO()做会话级标记 - INSTEAD OF 触发器始终计入总数，哪怕关掉
nested triggers也照算
PostgreSQL 报 “stack depth limit exceeded”：靠自己拦
它默认允许触发器内 UPDATE 同表，但每次都会再触发——所以你得手动判断嵌套深度，否则等栈溢出才报错。
- 首选方案是改用
BEFORE UPDATE，直接修改NEW.updated_at，不发新 SQL - 若必须用
AFTER，得在开头加：IF pg_trigger_depth() > 1 THEN RETURN; END IF; - 也可用会话级变量：
SET LOCAL trigger.depth = 1，再在触发器里检查 -
tg_op字段可用于区分事件类型，避免误判 INSERT/UPDATE 混合场景
Oracle 报 ORA-00036：50 层递归 SQL 是保护机制
这不是触发器专属问题，而是 Oracle 对所有递归 SQL（含触发器、物化视图刷新、函数索引维护）的统一栈深限制。一旦调用链超过 50 层，立刻中止。
- 典型原因是级联触发器循环：A 表触发器 → 更新 B 表 → B 表触发器 → 又更新 A 表
-
ORA-00036日志里通常带完整调用栈，重点看最后几层是否形成闭环 - 不能调高限制值，这是硬编码安全阀；唯一解法是拆链：把跨表更新逻辑移到应用层，或用异步消息队列解耦
- 用
DBMS_SUPPORT.START_TRACE或DBMS_MONITOR开启 trace，定位真实递归入口点
最易被忽略的一点：不同数据库对“递归”的定义完全不同。MySQL 是语法拦截，SQL Server 是栈深计数，PostgreSQL 是深度检测，Oracle 是递归 SQL 总量统计。拿 SQL Server 的 RECURSIVE_TRIGGERS 思路去套 MySQL 或 PostgreSQL，只会浪费时间。
