sql server中禁用嵌套触发器需执行sp_configure 'nested triggers', 0并reconfigure；pg需用会话变量标记；mysql无直接开关，须逻辑控制；oracle自治事务不适用，易致数据不一致。
SQL Server 中 sp_configure 'nested triggers' 怎么关
关掉嵌套触发器是限制递归最直接的手段，但不是所有场景都适用——它会影响所有触发器的嵌套行为，不只是你写的那个级联触发器。
执行前先确认当前值：
EXEC sp_configure 'nested triggers';
-
0表示禁用嵌套（即禁止一个触发器内再触发另一个触发器） -
1是默认值，允许嵌套，也就为递归开了门 - 修改后必须运行
RECONFIGURE才生效 - 注意：这个设置是实例级的，影响所有数据库，不能按库或按表控制
PostgreSQL 里怎么防 AFTER UPDATE 触发器无限循环
PG 没有全局开关，得靠触发器函数内部做守卫。核心思路是用 TG_LEVEL 或会话变量打标记，避免自己再触发自己。
- 在函数开头加判断：
IF current_setting('app.in_trigger', true) = 'true' THEN RETURN NEW; END IF; - 在真正要触发更新前，先设：
PERFORM set_config('app.in_trigger', 'true', true); - 记得更新完立刻还原：
PERFORM set_config('app.in_trigger', 'false', true); - 别用
pg_backend_pid()做标识——同一事务里多次调用触发器时 PID 不变，不可靠
MySQL 的 SQL_SAFE_UPDATES 能挡住递归触发器吗
不能。这个变量只限制没有 WHERE 或主键条件的 UPDATE/DELETE，对触发器是否递归完全没约束。
- MySQL 8.0+ 支持
max_sp_recursion_depth，但它管的是存储过程调用深度，不包括触发器 - 真要防递归，只能靠触发器逻辑里加状态字段或临时表记录已处理的
id - 比如在被更新表上加个
is_processing TINYINT DEFAULT 0，触发器开头查它，为 1 就退出 - 注意：这种字段要配合事务回滚清理，否则异常中断会导致后续操作卡死
Oracle 的 PRAGMA AUTONOMOUS_TRANSACTION 适合用来解递归吗
不适合，反而容易埋坑。自治事务会让触发器里的 DML 脱离原事务上下文，看似“跳出”了递归链，实则破坏了一致性。
- 如果主事务回滚，自治事务已提交的数据不会回滚，造成数据错乱
- 它不解决递归根源，只是把问题从“栈溢出”变成“数据不一致”
- 真正该做的是在触发器里检查
ORA_SYSEVENT和ORA_LOGIN_USER，结合业务状态字段跳过重复触发 - Oracle 12c+ 可用
DBMS_SESSION.SET_IDENTIFIER标记调用来源，比硬编码更可控
