SQL视图中嵌入当前用户标识行过滤需依赖数据库会话上下文函数：PostgreSQL用current_setting()或current_user，SQL Server用ORIGINAL_LOGIN()，MySQL 8.0+需应用层SET会话变量并校验非空，且必须收回底层表权限、仅授视图权限以防绕过。
SQL视图中如何嵌入当前用户标识进行行过滤
直接在视图定义里写死 WHERE user_id = 123 没用，每次换用户都得重建视图。真正可行的是依赖数据库运行时能识别会话上下文的函数，比如 PostgreSQL 的 current_user、session_user，或 SQL Server 的 SUSER_SNAME()；MySQL 8.0+ 可用 USER() 或自定义变量（需配合应用层 SET）。关键不是“能不能写 WHERE”，而是“WHERE 里能不能动态取到当前登录人”。
PostgreSQL 中用 current_setting() 实现更灵活的行级控制
硬编码函数有局限：比如多租户场景下，用户可能属于多个租户，或需要按角色/部门过滤。PostgreSQL 允许客户端在连接后执行 SET app.current_tenant = 'acme';，然后视图里用 WHERE tenant_id = current_setting('app.current_tenant', true)。注意第二参数 true 表示“未设置时不报错”，否则会因变量未定义导致查询失败。
- 必须在连接池配置中启用变量传递（如 PgBouncer 需设
ignore_startup_parameters = application_name） -
current_setting()返回 text 类型，若字段是 int，得显式转换：tenant_id = (current_setting('app.current_tenant', true)::int) - 该方式不依赖数据库用户账号，更适合应用多租户而非 DB 用户隔离
SQL Server 视图里用 ORIGINAL_LOGIN() 还是 SUSER_SNAME()
两者都返回登录名，但行为不同：ORIGINAL_LOGIN() 是连接建立时的原始登录名，即使后续用 EXECUTE AS 切换上下文也不会变；SUSER_SNAME() 返回当前执行上下文的登录名。行级权限通常要锁定“谁连进来的”，所以优先选 ORIGINAL_LOGIN()。
- 如果用 Windows 身份验证，返回值形如
DOMAIN\user，匹配前需考虑大小写和域前缀 - 视图中不能直接用
USER_NAME()（它返回数据库用户名，不是登录名），容易漏掉映射关系 - 记得给视图 SELECT 权限的同时，确保用户对底层表也有 VIEW DEFINITION 权限，否则可能报
The SELECT permission was denied
MySQL 8.0+ 视图无法直接调用 USER() 做行过滤？
MySQL 视图定义里允许 USER()，但它返回的是「主机名+用户名」格式（如 'app@10.0.1.5'），而业务表里存的往往是纯用户名或 ID。更糟的是，MySQL 不支持在视图中用子查询关联系统表来解析登录信息。实际做法是：应用层在连接后执行 SET @current_user_id = 123;，视图里写 WHERE owner_id = @current_user_id。但必须确认连接池不会复用连接并污染变量 —— 大多数现代驱动（如 MySQL Connector/J 8.0+）默认开启 useLocalSessionState=true，可安全使用会话变量。
- 不要用
@@session.xxx系统变量，它们只读或不可靠 - 视图创建后，若应用忘记 SET 变量，
@current_user_id为 NULL，WHERE 条件全失效，查不到任何数据 —— 这是静默失败点，务必在视图里加非空校验：WHERE owner_id = @current_user_id AND @current_user_id IS NOT NULL - MySQL 8.0.16+ 支持角色（ROLE），但角色不能直接用于视图 WHERE，仍得靠变量或应用传参
最易被忽略的是权限继承链：即使视图加了用户过滤，如果用户对底层表有直接 SELECT 权限，就能绕过视图查全量数据。必须回收表级权限，只授予视图权限，并确保视图定义用 SECURITY DEFINER（PostgreSQL/SQL Server）或对应机制，否则过滤逻辑形同虚设。
