SQL Server默认允许嵌套触发器（nested triggers=1），但禁止直接递归（RECURSIVE_TRIGGERS=OFF）；间接递归需禁用nested triggers。嵌套易致事务回滚失控，推荐用外键级联或显式存储过程替代。
SQL Server 默认允许触发器嵌套，但不等于默认允许递归
SQL Server 中，一个触发器执行时引发另一个表上的触发器（比如 titles 的 DELETE 触发器删数据 → 连带触发 titleauthor 的 DELETE 触发器），这叫「嵌套触发器」，默认是开启的。但同一个触发器自己反复调用自己（直接递归），或通过中间表绕一圈再回来（间接递归），默认是被禁止的。
-
nested triggers服务器配置项控制是否允许嵌套（默认为 1，即开启） -
RECURSIVE_TRIGGERS数据库选项控制是否允许**直接递归**（默认为 OFF） - 要彻底禁用间接递归，必须把
nested triggers设为 0 —— 单设RECURSIVE_TRIGGERS = OFF不够
怎么查和改嵌套/递归开关？
别猜，直接查配置。两个地方要确认：
- 查服务器级嵌套：运行
SELECT value_in_use FROM sys.configurations WHERE name = 'nested triggers'，返回 1 表示嵌套启用 - 查数据库级递归：运行
SELECT is_recursive_triggers_on FROM sys.databases WHERE name = DB_NAME()，1 表示该库允许直接递归 - 改服务器配置需
sp_configure+RECONFIGURE；改数据库选项用ALTER DATABASE ... SET RECURSIVE_TRIGGERS ON
注意：sp_configure 修改后必须执行 RECONFIGURE 才生效，否则只是“设了没用”。
为什么嵌套触发器容易出错？
最常见问题是事务回滚不可控。所有嵌套层级共享同一个事务上下文，只要任意一层触发器里抛错（比如约束冲突、空值插入、RAISERROR）、或没捕获异常，整个链路立刻回滚——你可能只删了一行，结果连前面已提交的 INSERT 都没了。
- 错误现象：执行一条
DELETE没报错，但数据没删成，也没进目标日志表 - 原因可能是某层触发器里
INSERT INTO del_save SELECT * FROM deleted失败（比如del_save字段类型不匹配） - 调试建议：在关键触发器开头加
PRINT 'Trig titleauthor_delete fired'，配合 SQL Server Profiler 或扩展事件看执行流 - 千万别依赖 PRINT 查逻辑分支 —— 它不保证输出顺序，且生产环境常被关掉
嵌套 vs. 显式级联，哪个更可控？
嵌套触发器不是实现级联操作的推荐方式。官方文档明确说：“不推荐按依赖于顺序的序列使用嵌套触发器”。真正稳定的做法是把逻辑收口到一处。
- 比如删除
titles同时清理titleauthor，优先考虑外键ON DELETE CASCADE，而不是靠触发器联动 - 若业务逻辑复杂（如要写审计日志+发消息+校验库存），用显式存储过程封装全部操作，由应用或作业调用，而非靠触发器“自动串起来”
- 触发器嵌套深度上限是 32 层，但实际到 5–6 层就极难维护；一旦某张中间表加了新触发器，整条链行为可能突变
嵌套机制本身没问题，问题在于它把耦合藏得太深——改一张表的触发器，可能让三张表之外的业务突然失败，而没人知道为什么。
