SQL触发器不能用于实现行级数据权限控制，因其仅响应INSERT/UPDATE/DELETE，完全不拦截SELECT，无法在查询阶段注入过滤条件，且易被JOIN、子查询等绕过；正确方案是RLS、会话感知视图或参数化存储过程。
SQL触发器不能用于实现行级数据权限控制——它根本不是干这个的，强行用会出安全漏洞和逻辑错乱。
为什么触发器不适合做行级权限
触发器在INSERT/UPDATE/DELETE执行后或执行前响应，但权限控制必须发生在查询（SELECT）阶段。用户执行SELECT * FROM orders时，触发器完全不触发，数据已全量返回。你没法用BEFORE SELECT——标准SQL里压根没有这个东西。
常见误用场景包括：在UPDATE触发器里检查“当前用户能否改这行”，但这只拦得住DML，拦不住SELECT；更糟的是，有人试图在INSERT触发器里重写语句或抛异常来模拟权限，结果导致应用报错、事务中断、审计日志失真。
- 触发器无法干预读操作，SELECT永远绕过它
- 即使对写操作加校验，也无法防止用户通过JOIN、子查询、UNION等方式间接获取越权数据
- 触发器逻辑分散在各表上，难维护、难审计、易被绕过（比如用临时表+INSERT SELECT）
真正该用的机制：RLS 或视图 + 会话变量
行级权限必须在查询计划生成阶段就注入过滤条件，让优化器能下推、走索引、避免全表扫描。主流方案只有三种，按优先级排序：
- PostgreSQL / SQL Server 2016+ / Oracle 12c+：直接用
CREATE POLICY开启行级安全策略（RLS），策略表达式可调用CURRENT_USER、current_setting('app.user_id')等会话上下文函数 - MySQL 8.0+：没有原生RLS，但可用
SQL SECURITY INVOKER视图 +USER()提取用户名，再配合SUBSTRING_INDEX(USER(), '@', 1)匹配业务字段；必须收回底层表权限，只授视图权限 - 所有数据库通用兜底法：动态拼WHERE（报表服务层）、或封装成带参数的存储过程（需严格校验输入，防SQL注入）
注意：CURRENT_USER在视图里基本无效（创建时求值），而current_setting()（PG）、ORIGINAL_LOGIN()（SQL Server）、USER()（MySQL）才是运行时可变的正确选择。
容易被忽略的权限逃逸点
哪怕用了RLS或视图，仍可能被绕过，关键在权限授予链是否闭环：
- 给用户授了视图
SELECT权，但忘了REVOKE SELECT ON base_table FROM user——用户可直接查原表 - PostgreSQL中RLS策略没设
FOR ALL或漏了USING和WITH CHECK区分读写逻辑，导致INSERT绕过校验 - SQL Server启用RLS后，没对用户显式
GRANT SELECT ON table，反而因策略依赖导致权限拒绝（策略生效前提是有基础权限） - MySQL视图用了
SQL SECURITY DEFINER（默认值），结果始终以定义者身份执行，USER()返回的是DBA账号而非登录用户
最危险的疏忽是：以为加了触发器就“安全了”，然后把底层表权限放开，等于在保险柜上贴张纸条说“请勿打开”。
