SQL视图本身不能实现真正的行级安全控制，真正起作用的是基表上的行级安全策略（RLS）配合权限隔离；PostgreSQL需启用RLS并创建策略，MySQL依赖视图+权限回收+DEFINER模拟，SQL Server应优先使用原生RLS并避免USER_NAME()等不可靠函数。
SQL 视图本身不能实现真正的行级安全控制，它只是查询封装层；真正起作用的是基表上的行级安全策略（RLS）配合权限隔离。
PostgreSQL 中视图 + RLS 的正确协作方式
在 PostgreSQL 里，试图靠 CURRENT_USER 或 SESSION_USER 写进视图定义来过滤数据是无效的——视图创建时这些函数就被求值为定义者（比如 postgres），不是查询时的实际用户。RLS 才是唯一可靠的行级守门人。
- 先启用 RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; - 再建策略，例如：
CREATE POLICY order_user_policy ON orders FOR SELECT USING (user_id = current_setting('app.user_id')::INT); - 视图只做投影：
CREATE VIEW my_orders AS SELECT id, amount, status FROM orders; - 确保应用连接后执行过
SET app.user_id = '123';，否则策略无法匹配 - 用目标角色连接测试：
EXPLAIN (VERBOSE) SELECT * FROM my_orders;，确认执行计划中出现 RLS 过滤条件
MySQL 中用视图模拟行级权限的关键约束
MySQL 没有原生 RLS，只能靠视图 + 权限回收 + SQL SECURITY DEFINER 组合实现“伪行级控制”，但极易失效。
- 必须显式声明
SQL SECURITY DEFINER，且DEFINER是高权限账号（如'admin'@'localhost'） - 视图定义中避免硬编码
SUBSTRING_INDEX(USER(), '@', 1)—— 应用连接池或复杂 host 名会导致截断错误 - 更稳妥的做法是写一个
SQL SECURITY DEFINER存储函数get_current_user_id()，查映射表转换登录名到业务 ID - 必须执行
REVOKE SELECT ON mydb.orders FROM 'alice'@'%';，再GRANT SELECT ON mydb.my_orders TO 'alice'@'%'; - 检查权限残留：
SHOW GRANTS FOR 'alice'@'%';输出里不能出现原始表名
SQL Server 视图里写 USER_NAME() 或 SYSTEM_USER 为什么危险
这两个函数返回的是数据库用户（database principal），不是登录名（login）。在 EXECUTE AS、跨库调用或代理场景下，结果可能为 NULL 或错乱，导致策略失效。
- 改用
ORIGINAL_LOGIN()（稳定返回实际登录名）或SESSION_CONTEXT(N'user_id')（需应用层提前调用sp_set_session_context设置） - 优先启用原生 RLS：
CREATE SECURITY POLICY SalesFilter ADD FILTER PREDICATE Security.fn_securitypredicate(sales_rep_id) ON dbo.orders; - 谓词函数
fn_securitypredicate必须轻量、无副作用，避免递归或复杂 JOIN，否则影响执行计划下推 - 测试必须用真实业务账号连接，
sa或dbo直连会绕过策略检查
最容易被忽略的点：视图定义中任何对字段的函数处理（比如 MD5(email)、SUBSTRING(phone, 1, 3)）会让该字段失去索引能力——如果这个字段还要用于 WHERE 过滤，性能会断崖式下跌。脱敏和查询效率之间需要权衡，别为了“看起来安全”牺牲基础性能。
