触发器不适合做角色判断，因其无法获取应用层角色信息、易引发锁争用与执行计划不稳定；唯一安全模式是owner_id归属锁定，需应用层传入用户ID并用CONTEXT_INFO传递。
不能用触发器实现“基于角色”的行级安全控制——它本质上是基于业务用户ID的归属校验，不是角色权限判断。 SQL Server 触发器里拿不到应用层的角色信息，CURRENT_USER 和 SUSER_SNAME() 返回的是数据库登录主体，和业务系统里的“管理员”“部门主管”等角色完全无关。强行在触发器里查角色表做动态授权，会引发锁争用、执行计划不稳定、所有权链断裂等生产级风险。
为什么触发器不适合做角色判断
触发器执行时上下文极度受限：无法访问会话级变量（如 SESSION_CONTEXT）以外的外部状态，而 SESSION_CONTEXT 在 Navicat、SSMS 默认连接中不自动传递；角色映射关系通常存在业务库的 user_role 或 dept_permission 表中，每次 INSERT/UPDATE 都去 JOIN 这类表，会把 DML 变成“带锁查询”，高并发下极易阻塞写入；SQL Server 不允许触发器中显式开启事务或使用 TRY/CATCH 外包逻辑，错误只能靠 RAISERROR 中断，无法优雅降级。
- 常见错误现象：
INSERT INTO orders触发器里写IF EXISTS (SELECT 1 FROM appdb.dbo.user_role WHERE user_id = @uid AND role_name = 'dept_manager')→ 每次插入都锁住user_role表，订单入库延迟飙升 - 真正可控的方案是：应用层根据当前用户ID预查其角色+数据范围（例如“可查看 dept_id IN (101,102) 的所有订单”），再把过滤条件下推到 SQL 查询中，而不是让触发器回查
- 若必须用数据库端控制，应改用 SQL Server 2016+ 原生的
CREATE SECURITY POLICY+RULE，它基于执行上下文自动注入谓词，不依赖触发器
触发器里能安全做的只有 owner_id 归属锁定
这是唯一被验证过、可上线的触发器行级控制模式：强制每条记录的 owner_id 字段必须等于当前业务用户ID，且该 ID 必须由应用层在事务开始后、DML 前显式传入。
- 应用层调用：
SET CONTEXT_INFO 0x75373839（ASCII “u789” 的十六进制） - 触发器中读取：
RTRIM(CONVERT(VARCHAR(128), CONTEXT_INFO()))，必须加RTRIM()，否则尾部空格导致比对失败 - INSERT：检查
inserted.owner_id = @app_user_id，若业务要求强制归属，应禁止客户端传owner_id，改由触发器UPDATE inserted SET owner_id = @app_user_id - UPDATE：必须同时验证
deleted.owner_id = @app_user_id（原属自己）且inserted.owner_id = deleted.owner_id（未篡改归属），除非业务明确允许转交 - DELETE：只查
deleted.owner_id = @app_user_id；inserted在 DELETE 触发器中为空，不能引用
多行操作时最容易踩的坑
触发器面对批量 DML（如 INSERT INTO t VALUES (...), (...)）时，inserted 和 deleted 是表，不是单行变量。用 SELECT @uid = owner_id FROM inserted 会导致多行赋值报错，或仅取第一行造成漏校验。
- 正确写法必须用集合逻辑：
IF NOT EXISTS (SELECT 1 FROM inserted i WHERE i.owner_id != @app_user_id) RETURN - 禁止在触发器里写游标遍历
inserted—— 性能差且破坏集合处理原则 - 所有校验必须放在
AFTER触发器中，INSTEAD OF虽然可控但需重写全部 DML 逻辑，维护成本极高 - 测试时务必用批量语句验证，例如：
INSERT INTO orders (product, amount) VALUES ('A', 100), ('B', 200)
真正的复杂点不在触发器怎么写，而在于应用层能否稳定、无遗漏地设置 CONTEXT_INFO —— 任何一次忘记设置，或者中间件连接池复用导致上下文残留，都会让整套控制失效。这比写错一行 SQL 危险得多。
