AFTER UPDATE触发器无法拦截危险更新，因其在UPDATE提交后才执行；真正能拦截的是INSTEAD OF UPDATE触发器，它替代原操作，在数据修改前校验并控制执行。
为什么AFTER UPDATE触发器拦不住危险更新
AFTER UPDATE触发器在UPDATE语句**已成功提交之后**才运行，此时数据已被改写，拦截毫无意义。你看到的“拦截失败”，其实是逻辑错觉——它根本没机会阻止，只能事后补救或报错回滚，但业务状态已脏。
常见错误现象：想用AFTER触发器检查status字段是否被非法改成'deleted'，结果发现日志里有记录、但数据已经变了；或者触发器里RAISERROR抛异常，事务却因前置操作已提交而无法整体回滚（尤其跨多语句批处理时）。
- AFTER触发器不参与锁竞争，也不影响原UPDATE的加锁行为
- 它访问的是
inserted和deleted表，但这两张表反映的是“已完成变更”的快照 - 若原UPDATE本身没走事务或用了
NOLOCK，触发器甚至可能读到不一致的中间态
INSTEAD OF UPDATE才是真拦截点
INSTEAD OF UPDATE触发器会**替代原始UPDATE执行**，把控制权完全拿到手。它不自动修改数据，你得自己写UPDATE ... FROM inserted逻辑——这正是做校验的黄金窗口。
使用场景：禁止非管理员修改is_admin = 1的用户、拦截对created_at字段的重写、阻断未带租户上下文的跨租户更新。
- 必须显式声明
INSTEAD OF UPDATE，不能混用AFTER - 校验失败时直接
RETURN或RAISERROR，原UPDATE彻底不会发生 - 若要放行，必须手动执行
UPDATE target_table SET ... FROM inserted，且WHERE条件必须严格匹配inserted.id等主键字段 - 注意：INSTEAD OF触发器不自动继承原语句的锁行为，如需防止并发覆盖，得在触发器内加
SELECT ... WITH (UPDLOCK, ROWLOCK)先占住行
租户ID校验必须用SESSION_CONTEXT，别碰CURRENT_USER
CURRENT_USER、SUSER_NAME()返回的是SQL登录名，不是业务租户ID。靠它们鉴权等于拿门禁卡刷电梯——能进楼，但按不到你家楼层。
正确做法是应用层每次请求连接后调用sp_set_session_context传入租户标识，触发器里用SESSION_CONTEXT(N'tenant_id')读取。否则任何有DB权限的用户都能绕过租户隔离。
- 读取时必须写成
DECLARE @tenant_id NVARCHAR(128) = SESSION_CONTEXT(N'tenant_id')，不能省略类型声明 - 比较要用
IS NOT DISTINCT FROM，避免@tenant_id = inserted.tenant_id在任一为NULL时恒为FALSE - DELETE/UPDATE触发器必须从
deleted表核验原租户ID，防止用户先UPDATE再DELETE来逃逸 - 字段类型不匹配会静默失败：比如
tenant_id列是UNIQUEIDENTIFIER，就得CAST(SESSION_CONTEXT(N'tenant_id') AS UNIQUEIDENTIFIER)
性能与死锁风险比想象中更近
INSTEAD OF触发器里如果查其他表（比如校验租户白名单）、或调用函数（比如fn_check_quota()），很容易引发锁等待甚至死锁——特别是当多个触发器嵌套或涉及同一批主键时。
一个常被忽略的细节：UPDATE语句本身在无索引WHERE条件下可能升级为表锁，而触发器里的SELECT ... WITH (UPDLOCK)又试图加行锁，两者冲突直接卡死。
- 所有WHERE条件必须命中索引，尤其是租户ID+主键组合索引
- 避免在触发器里做远程查询、HTTP调用、或写入日志表（除非日志表单独建库并设为READ_COMMITTED_SNAPSHOT）
- 测试时用
SELECT * FROM sys.dm_exec_requests WHERE blocking_session_id 0抓实时阻塞链 - 上线前务必压测：模拟50+并发UPDATE同一行，观察
sys.dm_os_waiting_tasks里LCK_M_U等待是否飙升
真正拦住高危UPDATE的关键，不在触发器有多复杂，而在它是否在数据落盘前就握住了控制权——INSTEAD OF是唯一满足这点的机制，其余都是马后炮。但它的代价是责任全移交给开发者：每一条放行的UPDATE都得亲手写，每一个校验分支都得自己兜底。
