sql server不支持select触发器，无法用触发器拦截或控制行级读权限；读权限必须通过view封装where条件或sql server 2016+的行级安全（rls）实现，低版本仅能依赖视图加应用层传参模拟过滤。
SQL Server 触发器无法做行级读权限控制
直接用触发器拦截 SELECT 是不可能的——SQL Server 不支持 SELECT 触发器，写 CREATE TRIGGER ... ON table FOR SELECT 会报错 ERROR: syntax error at or near "SELECT"。很多人卡在这一步，以为是语法写错，其实是标准不支持。
常见错误现象：在触发器里查 sys.dm_exec_sessions 拿当前登录名，再 join 权限表过滤数据，结果发现触发器根本没运行；或者试图在 INSTEAD OF SELECT 里重写查询，但 SQL Server 不识别这个语法。
- 读权限必须靠
VIEW（封装 WHERE 条件）或ROW LEVEL SECURITY (RLS)（SQL Server 2016+ 支持）实现 - 如果数据库版本低于 2016，只能用视图 + 应用层传参（如
@user_id）模拟行级过滤 - 触发器能做的，仅限于
INSERT/UPDATE/DELETE时校验写权限，且必须配合应用显式传入角色上下文
BEFORE 类型不存在，用 INSTEAD OF 替代但有代价
SQL Server 没有 BEFORE INSERT，只有 INSTEAD OF INSERT。它会完全替代原操作，意味着你得手动 INSERT INTO target_table SELECT ... FROM inserted，否则数据就丢了。
容易踩的坑：
- 忘记在
INSTEAD OF INSERT里执行实际插入，导致“无声失败”——语句不报错，但数据没进表 - 在触发器里调用
ORIGINAL_LOGIN()或SUSER_SNAME()，拿到的是连接池用户（如app_pool@localhost），不是真实业务角色 - 误把权限校验逻辑和数据补全混在一起：比如自动填
created_by时覆盖了应用传来的合法值
实操建议：校验失败必须用 RAISERROR('无权操作', 16, 1) 并 RETURN，不能只改 inserted 里的字段就结束。
角色信息必须由应用层显式注入
SQL Server 触发器里拿不到 HTTP Header、JWT payload 或中间件塞的租户 ID。CURRENT_USER、SESSION_CONTEXT() 这些都得靠应用在每次请求前主动设置。
正确做法：
- 应用执行 SQL 前，先跑
EXEC sp_set_session_context @key = N'role_id', @value = N'editor' - 触发器里用
SESSION_CONTEXT(N'role_id')读取，而不是依赖登录名 - 避免用
APP_NAME()或HOST_NAME()做判断——它们可被客户端伪造
注意：SESSION_CONTEXT 是会话级的，连接复用（如连接池）时必须每次请求都重设，否则可能残留上一个用户的值。
DDL 触发器能拦结构变更，但拦不住 TRUNCATE
想防用户删表或改字段，可以用 FOR DROP_TABLE 或 FOR ALTER_TABLE 触发器，但 TRUNCATE TABLE 是个例外：它不走 DML 触发器，也不走 DDL 触发器，完全绕过所有触发逻辑。
典型风险场景：
- 用户属于
db_datawriter角色，能执行TRUNCATE却不会触发任何校验 - 触发器里写了
IF SUSER_SNAME() NOT IN ('sa', 'admin') ROLLBACK，对TRUNCATE完全无效
真正有效的防护只有两条路：一是收回 ALTER 和 CONTROL 权限，二是用更细粒度的角色（如只给 INSERT/UPDATE，不给 ALTER）。触发器只是补充，不是防线主体。
