sql server触发器递归调用必致栈溢出，需同时禁用数据库级recursive_triggers和服务器级nested triggers；常见于after触发器内更新同表，应优先用instead of或trigger_nestlevel()防护。
SQL Server 的触发器递归调用会直接爆栈，不是“可能”，而是只要开启且逻辑闭环就必现
SQL Server 默认允许触发器递归，但实际业务中几乎不需要
SQL Server 有两个层级的递归控制：RECURSIVE_TRIGGERS 数据库级开关（默认 OFF），和 sp_configure 'nested triggers' 服务器级开关（默认 1，即启用）。很多人只关了前者，却没意识到后者才是底层开关——只要它为 1，哪怕数据库设为 RECURSIVE_TRIGGERS = OFF，INSERT → 触发器 → UPDATE → 同表触发器 这类间接递归仍可能发生。
- 检查当前值：
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsRecursiveTriggersEnabled')和EXEC sp_configure 'nested triggers' - 真正禁用递归触发器，两个都得设：
ALTER DATABASE [your_db] SET RECURSIVE_TRIGGERS OFF+EXEC sp_configure 'nested triggers', 0; RECONFIGURE - 注意：
RECURSIVE_TRIGGERS是数据库属性，切换数据库后需重新确认；nested triggers是实例级，影响所有数据库
触发器里调用同表 UPDATE/INSERT 是最常见爆栈路径
比如一个 AFTER INSERT 触发器里执行 UPDATE same_table SET x = y WHERE id IN (SELECT id FROM inserted)，若该表还有 AFTER UPDATE 触发器，就构成隐式递归链。SQL Server 不做深度检测，只看是否触发了“本表的另一触发器”，一旦满足条件就压栈，100 层左右就会 StackOverflowError。
- 避免在触发器内修改当前表：改用
INSTEAD OF触发器接管逻辑，或把更新逻辑移到应用层 - 若必须更新，加守卫条件：
IF NOT EXISTS (SELECT * FROM sys.dm_exec_sessions WHERE session_id = @@SPID AND program_name LIKE '%trigger%')（不推荐，仅作临时规避） - 更可靠的做法：在触发器开头用
IF TRIGGER_NESTLEVEL() > 1 RETURN主动退出深层调用
误开 RECURSIVE_TRIGGERS 后堆栈溢出的表现很隐蔽
它不会立刻报错，而是在执行某些看似正常的语句时突然卡死、连接中断，或日志里出现 Event loop exception 和 StackOverflowError ——这和 DBeaver 解析复杂 SQL 时的崩溃现象高度相似，容易误判为客户端问题。
- 典型诱因：DBA 为调试临时开启
RECURSIVE_TRIGGERS，事后忘记关闭；或部署脚本里硬编码了SET RECURSIVE_TRIGGERS ON - 验证方式：在 SSMS 中执行
SELECT TRIGGER_NESTLEVEL()，插入一行触发后立即查，若返回值 ≥ 2 就说明已进入递归 - 紧急恢复：断开所有连接，用
master数据库执行ALTER DATABASE [db] SET RECURSIVE_TRIGGERS OFF WITH ROLLBACK IMMEDIATE
真正危险的不是“能不能递归”，而是“有没有意识到自己正在递归”。TRIGGER_NESTLEVEL() 是唯一能 runtime 检测的手段，任何含跨触发器操作的逻辑，都应该把它当作 if 条件写进第一行。
