禁用约束（NO CHECK CONSTRAINT）不影响AFTER触发器执行——触发器独立于约束机制，只要启用（is_disabled=0）且DML发生即运行；其执行顺序固定在约束检查之后，禁用约束仅跳过校验，不跳过触发器调用。
禁用约束（ALTER TABLE ... NOCHECK CONSTRAINT）不会阻止 AFTER 触发器执行 —— 它们根本不在同一个执行层级上，也不受约束开关影响。
触发器和约束的执行顺序是硬编码的，不可跳过
SQL Server 对 DML 操作的处理流程是固定的：先检查约束 → 若全部通过，再执行 AFTER 触发器。禁用约束只是跳过「检查」环节，但不跳过「触发器调用」这一步。
-
NO CHECK CONSTRAINT只让约束校验失效，不会修改触发器注册状态或执行计划 - 哪怕表上所有约束都被禁用，只要触发器是启用的（
is_disabled = 0），它仍会在 INSERT/UPDATE/DELETE 后照常运行 - 如果你看到“约束没生效但触发器跑了”，这不是 bug，是设计如此 —— 触发器不是约束的附属品，它是独立事件响应机制
为什么 sp_settriggerorder 对禁用约束场景毫无作用
这个系统存储过程只管 AFTER 触发器之间的相对位置，和约束完全无关。它解决不了“该不该触发”的问题，只解决“多个触发器谁先谁后”这种次要问题。
- 你不能用
sp_settriggerorder让某个触发器“只在约束通过时才执行”——它没有这个语义 - 即使把触发器设为
FIRST，它依然会在约束被禁用的情况下执行；设为LAST也一样 - 真正影响触发器是否运行的，只有两个条件：
is_disabled = 0和对应 DML 语句实际发生
AFTER 触发器里访问 inserted/deleted 时要注意什么
禁用约束后，数据可能处于违反业务规则的状态（比如外键指向不存在的记录、CHECK 值越界），而触发器仍会收到这些“脏数据”。这时候直接读写就容易出错。
- 不要假设
inserted中的值一定合法 —— 外键列可能为空或无效，CHECK 字段可能超出范围 - 避免在触发器里做
SELECT ... FROM referenced_table WHERE id IN (SELECT ref_id FROM inserted)这类隐式 JOIN，可能因外键失效而返回空或报错 - 如需强一致性保障，应在触发器开头加显式校验，例如：
IF NOT EXISTS(SELECT 1 FROM parent_table p WHERE p.id = i.parent_id) ROLLBACK - INSTEAD OF 触发器不受此影响，但它本身就不能和约束共存于同一操作路径中
最常被忽略的一点：很多人以为禁用约束是为了“绕过校验顺便跳过触发器”，结果上线后发现审计日志多了一堆非法数据 —— 因为触发器还在默默跑，而它处理的数据已经脱离约束保护了。
