PostgreSQL视图中无法直接用CURRENT_SETTING('app.tenant_id')过滤租户，因其静态编译且函数不可用于视图；应改用SECURITY DEFINER函数封装动态查询，并确保会话变量预设、权限配置及连接池正确处理。
视图里加 WHERE tenant_id = CURRENT_SETTING('app.tenant_id') 行不通
PostgreSQL 的 CURRENT_SETTING() 确实能读会话变量，但视图定义是静态的，创建时就编译好了，运行时不会重新解析表达式里的函数调用——它会被当成常量处理，或者直接报错“函数不可用于视图”。更常见的是执行时报 ERROR: unrecognized configuration parameter "app.tenant_id"，因为会话变量还没设，或权限不足。
真正可行的方案：用 SECURITY DEFINER 函数封装查询逻辑
把租户过滤逻辑藏进函数，再让视图调用该函数，才能在每次查询时动态生效。关键点有三个：
-
CREATE FUNCTION必须声明为SECURITY DEFINER，否则函数内无法读取调用者会话上下文 - 函数返回
SETOF your_table，内部用RETURN QUERY SELECT ... WHERE tenant_id = current_setting('app.tenant_id', true)::uuid - 视图定义直接
SELECT * FROM your_tenant_safe_function()，不写任何WHERE - 确保应用连接数据库前已执行
SET app.tenant_id = 'xxx';，且该参数名在postgresql.conf的custom_variable_classes中注册过
MySQL / SQL Server 用户注意：原生不支持会话级租户变量穿透视图
MySQL 没有 CURRENT_SETTING 对应机制；SQL Server 的 SESSION_CONTEXT() 虽然可用，但在视图中直接调用会导致“无法绑定”错误或执行计划缓存污染。实际做法是：
- MySQL：改用
PREPARE + EXECUTE动态拼接tenant_id，但这就不是视图了；更稳妥的是在应用层强制所有查询带WHERE tenant_id = ? - SQL Server：用内联表值函数（
ITVF）替代视图，参数显式传入@tenant_id，再由应用统一注入——视图本身不能接收参数 - 两者共性陷阱：别依赖
USER()或SUSER_NAME()推导租户，多租户下用户和租户不是一一映射关系
绕不开的权限与部署细节
哪怕函数+视图跑通了，漏掉下面任意一项都会导致隔离失效：
- 函数所有者必须是超级用户或拥有
SET权限的账号，否则CURRENT_SETTING返回空或报错 - 应用连接池必须支持 per-request 设置会话变量（如 PgBouncer 需开启
server_reset_query并禁用事务池化） - 视图不能被
GRANT SELECT ON ALL TABLES批量授权——必须单独GRANT SELECT ON your_view，否则租户可能绕过函数直查基表 - 测试时务必用真实租户账号连库验证，别只在 psql 里
SET后手动查，那掩盖了连接池重用会话变量的 bug
最易忽略的是连接池对会话变量的复用行为——一个连接被多个请求轮用时，app.tenant_id 可能残留上个租户的值。这问题不会在本地调试暴露，只在线上流量混杂时爆发。
