不能用触发器实现基于角色的行级权限控制，因其无法拦截SELECT操作；RLS才是正确方案，通过谓词函数与安全策略在查询执行时动态过滤数据。
不能用触发器实现基于角色的行级权限控制——它既不可靠，也不符合SQL Server的设计约束。 触发器只能响应 INSERT/UPDATE/DELETE，无法拦截或改写 SELECT 行为；而“基于角色的行级权限”本质是读取时动态过滤数据，必须由查询执行引擎在运行时介入，不是靠 DML 操作兜底能解决的。
为什么 AFTER UPDATE 触发器拦不住越权读取
有人试图在 AFTER UPDATE 里检查 IS_MEMBER('role_support')，再 ROLLBACK 非法修改——这只能阻止写操作，对 SELECT * FROM orders 完全无效。用户连上数据库后直接查表，触发器根本不会触发。更危险的是，这种逻辑容易被绕过：比如先 INSERT 伪造一条归属自己的记录，再通过视图或 JOIN 暴露他人数据。
RLS（行级安全性）才是正确入口
SQL Server 2016+ 原生支持 RLS，通过内联表值函数 + 安全策略实现真正的行级过滤：
- 创建谓词函数，返回
WHERE owner_dept = USER_NAME()或IS_MEMBER('role_manager') = 1 - 用
CREATE SECURITY POLICY将函数绑定到目标表 - 策略自动作用于所有
SELECT/UPDATE/DELETE，无需改应用 SQL
示例函数：
CREATE FUNCTION dbo.fn_securitypredicate(@owner_dept AS sysname)
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS fn_securitypredicate_result
WHERE @owner_dept = USER_NAME() OR IS_MEMBER('db_owner') = 1;
触发器唯一可行的补位场景：写入时强制归属校验
如果业务要求“用户只能插入自己部门的数据”，可在 INSTEAD OF INSERT 触发器中做硬性检查，但必须配合应用层显式传参：
- 应用执行
EXEC sp_set_session_context @key=N'user_dept', @value=N'HR' - 触发器读取
SESSION_CONTEXT(N'user_dept')，对比INSERTED.owner_dept - 不匹配则
THROW 50000, 'Dept mismatch', 1
注意：CONTEXT_INFO 已过时，SESSION_CONTEXT 是 SQL Server 2016+ 推荐方式，且需开启 SET ANSI_NULLS ON 等兼容选项。
真正难的不是写触发器，而是分清“谁该在什么层做权限判断”：RLS 处理读、GRANT/REVOKE 控制列级可见性、加密保护敏感字段、审计日志追踪越权尝试——单靠触发器拼凑权限体系，迟早会在某次紧急上线后发现客服能查到财务工资单。
