SQL Server 不支持按 Session 或条件动态跳过触发器，但可通过 DISABLE/ENABLE TRIGGER 或 ALTER TABLE ... DISABLE TRIGGER 精确控制单个触发器状态；必须显式指定触发器名和作用对象（表/视图），语法错误、权限不足或对象名未加括号均会导致失败；禁用后需查 sys.triggers 的 is_disabled 字段确认生效，且操作不可回滚，易引发数据一致性风险。
SQL Server 不支持按 Session 或条件动态跳过触发器，但可以精确控制单个触发器的启用/禁用状态——关键在于用对语法、作用域和权限。
DISABLE TRIGGER 和 ENABLE TRIGGER 的正确写法
必须显式指定触发器名和作用对象（表/视图），不能只写触发器名。常见错误是漏掉 ON 子句或写错对象路径。
-
DISABLE TRIGGER [schema].[trigger_name] ON [schema].[table_name]是最安全的方式，比如DISABLE TRIGGER dbo.tri_insalary ON dbo.tb - 也可以用
ALTER TABLE [schema].[table_name] DISABLE TRIGGER [trigger_name]，效果等价，但仅适用于 DML 触发器 - 不要写成
DISABLE TRIGGER tri_insalary—— 缺少ON会报错：Incorrect syntax near the keyword 'TRIGGER' - 触发器名和表名带特殊字符或空格时，必须用
QUOTENAME()或方括号包裹，否则执行失败
为什么 ALTER TABLE ... DISABLE TRIGGER 更常用？
它语义更明确、权限要求更低（只需对表有 ALTER 权限），且在 SSMS 图形界面里右键“禁用”实际就走这条路径。
-
ALTER TABLE dbo.tb DISABLE TRIGGER tri_insalary直接生效，无需额外GO分隔（但批量脚本中仍建议加） - 它不支持
ALL，只能操作单个触发器或写ALL表示该表全部触发器，比如ALTER TABLE dbo.tb DISABLE TRIGGER ALL - DDL 触发器（
ON DATABASE或ON ALL SERVER）不能用ALTER TABLE，必须用DISABLE TRIGGER ... ON DATABASE - 如果触发器在另一个 schema 下（如
Person.uAddress），ALTER TABLE必须带上 schema：ALTER TABLE Person.Address DISABLE TRIGGER uAddress
禁用后怎么确认真的生效了？
别信“命令已成功”，要查系统视图。很多线上事故源于误以为禁用了，其实没生效。
- 执行后立即查：
SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('dbo.tb') -
is_disabled = 1才表示已禁用；is_disabled = 0说明仍启用，可能是权限不足或对象名写错 - 如果触发器属于视图，
parent_id要用OBJECT_ID('dbo.your_view')，不是基础表 - 禁用操作本身不记录在事务日志中，所以不能靠事务回滚来“撤销禁用”——必须手动
ENABLE TRIGGER
容易被忽略的副作用和风险点
禁用触发器本身很快，但影响可能持续数小时甚至数天，尤其当触发器承担数据一致性职责时。
- INSTEAD OF 触发器被禁用后，对视图的
INSERT会直接报错View or function 'xxx' is not updatable，而不是“静默跳过” - 禁用期间所有会话对该表的 DML 都绕过触发逻辑，包括审计、统计更新、级联写入等——不是“只跳过你这次操作”
- 复制环境里，禁用触发器可能中断合并复制（因为 SQL Server 在发布数据库中依赖触发器捕获变更）
- 临时禁用后忘记启用，或者启用语句执行失败但没检查
is_disabled，会导致后续业务逻辑长期处于“半残缺”状态
