SQL触发器嵌套过深必然导致栈溢出，因SQL Server硬限32层、MySQL存储过程默认禁用递归；需同时关闭RECURSIVE_TRIGGERS和nested triggers，并用TRIGGER_NESTLEVEL()防护或改用INSTEAD OF触发器。
SQL触发器嵌套过深直接导致调用栈溢出，不是“可能”，而是只要达到引擎硬限制（SQL Server 为 32 层，MySQL 存储过程默认 0 或可设但不可超限），就必然崩溃——它不看逻辑是否合理，只数当前执行路径压栈次数。
SQL Server 触发器递归与嵌套是两回事，但都吃栈空间
很多人混淆 RECURSIVE_TRIGGERS 和 nested triggers：前者控制“同名触发器能否再进自己”，后者才是底层开关，决定“AFTER INSERT → UPDATE → 同表AFTER UPDATE”这类跨类型间接调用是否被允许。只要 nested triggers = 1（默认值），哪怕数据库设了 RECURSIVE_TRIGGERS = OFF，只要触发链存在，每进一层就 +1 栈帧。
-
TRIGGER_NESTLEVEL()返回的是当前会话中所有触发器、存储过程、UDF、sp_executesql的总层数，不是单指触发器嵌套 - 日志表、审计表这些“看起来安全”的目标，若自带
AFTER INSERT触发器，一次INSERT INTO audit_log就额外 +2 层（EXEC + INSERT 触发） -
WITH (NOLOCK)不绕过触发器，只跳过锁；想避免激活，得把 DML 改成INSERT ... SELECT FROM ... WITH (READPAST)或彻底移出触发器
为什么 IF TRIGGER_NESTLEVEL() > 1 RETURN 只能兜底，不能根治
这个守卫语句在触发器开头加，确实能拦住第二层及以后的调用，但它掩盖了设计缺陷：真正的问题是业务逻辑不该在触发器里闭环更新同表。比如组织架构表上建 AFTER UPDATE 去级联改 manager_path，只要更新自身字段，就又触发新一层——5~6 层内就逼近 32 限。
- 它不解决根本路径：触发器 → 存储过程 → INSERT → 另一触发器，这种链式调用仍会累加
@@NESTLEVEL - 别依赖
sys.triggers.is_disabled判断——嵌套限制是运行时检查，和启用状态无关 - 更可靠的做法是抽到带
@depth INT = 1参数的存储过程里，每次递归前显式判断：IF @depth > 25 BEGIN RETURN; END
MySQL 的递归存储过程爆栈比 SQL Server 更早暴露
MySQL 默认 max_sp_recursion_depth = 0（禁用），一旦设为非零值（如 SET max_sp_recursion_depth = 1000），又没写终止条件，就会报 ERROR 1456 (HY000): Recursive limit exceeded；但如果客户端是 Java（如 DBeaver），还可能在解析阶段就因 AST 过深触发 JVM StackOverflowError，现象是连接突然中断，而非明确报错。
- 该参数是会话级，重连即失效；全局生效需写进
my.cnf并重启 - CTE 在 MySQL 8.0+ 才支持，且仍受
cte_max_recursion_depth控制，默认 1000，建议上线前用最大深度边界值测试 - 视图嵌套不要超过 3 层，否则优化器放弃代价估算，执行计划随机漂移
最易被忽略的一点：堆栈溢出往往不报错，而是表现为查询卡死、SSMS 连接中断、DBeaver 崩溃或日志里零散出现 Event loop exception ——这时候别急着调大内存或栈大小，先查 TRIGGER_NESTLEVEL() 或 @@NESTLEVEL，盯住每一处 EXEC、INSERT/UPDATE/DELETE 和触发器定义。
