直接禁用表级触发器需用disable trigger语句并明确指定on表名，如disable trigger trreadonly_teacher on dbo.teacher；漏on子句或schema错误将报错；须查sys.triggers中is_disabled=1确认生效，禁用期间持sch-m锁影响并发。
直接禁用表级触发器，用 DISABLE TRIGGER 语句即可，不需要删重建或改权限。
DISABLE TRIGGER 语法必须带 ON 表名
SQL Server 不允许只写触发器名就禁用——必须明确指定作用对象。常见错误是漏掉 ON 子句或写错表名：
-
DISABLE TRIGGER trReadOnly_Teacher→ 报错：缺少 ON 子句 -
DISABLE TRIGGER trReadOnly_Teacher ON dbo.Teacher→ 正确（推荐显式写 schema） -
DISABLE TRIGGER ALL ON Teacher→ 禁用该表上所有触发器，注意不是ALL触发器名
如果表在非 dbo schema 下（比如 sales），必须写成 DISABLE TRIGGER tr_name ON sales.Teacher，否则会提示“找不到对象”。
禁用后如何确认是否生效
不能只靠执行不报错来判断，得查系统视图：
- 运行
SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('Teacher') - 返回
is_disabled = 1才算真正禁用成功 -
sys.triggers中的parent_id是表对象 ID，不是名称字符串
别依赖 sp_helptrigger 输出——它不显示 is_disabled 状态，容易误判。
并发场景下禁用触发器的风险点
禁用操作本身是 DDL，会持有表级 SCH-M（schema modification）锁，期间任何 DML 都会被阻塞。尤其要注意：
- 在业务高峰期执行
DISABLE TRIGGER ... ON big_table可能导致连接堆积 - 如果同时有其他会话正在执行涉及该表的查询（尤其是带
WITH (NOLOCK)的），也可能被锁住 - 不要在事务里禁用触发器再做大量 DML——万一回滚，触发器状态不会自动恢复
临时禁用建议加注释说明用途和预期启用时间，避免被后续维护者误认为“已废弃”。
真正麻烦的不是怎么禁用，而是禁用后忘了启用，或者启用时没验证逻辑是否回归——特别是涉及 INSTEAD OF 类触发器，一旦失效，写入可能静默失败或绕过校验。
