视图本身不能实现自动隔离，真正自动生效的是行级安全策略（RLS）；PostgreSQL中current_setting()可写入视图WHERE，但须满足三条件：连接后执行SET、变量加入custom_variable_classes、类型强转（如::uuid），且不适用于物化视图。
视图本身不能实现“自动”隔离，它只是一层查询封装；真正能自动生效的只有行级安全策略（RLS），视图只是辅助手段——用错就等于没隔离。
PostgreSQL 中 current_setting() 能不能直接写在视图 WHERE 里？
能，但必须满足三个硬性条件，缺一不可：
- 应用每次建连后必须执行
SET app.current_tenant_id = 't123'，且该变量名已加入postgresql.conf的custom_variable_classes -
current_setting()返回值类型要和字段匹配，比如tenant_id是 UUID 类型，就得强转：::uuid，否则查询直接失败 - 不能用于物化视图（
MATERIALIZED VIEW），因为current_setting()是 volatile 函数，物化视图不支持
常见错误是忘记在连接池初始化脚本里加 SET，导致所有请求查不到数据，或漏掉类型转换，报 ERROR: operator does not exist: uuid = text。
MySQL 视图里怎么模拟租户过滤？
做不到真正意义上的动态过滤——MySQL 视图无法读取会话变量运行时值。
-
@current_tenant_id是用户变量，不跨语句持久，视图定义中写WHERE tenant_id = @current_tenant_id实际上读的是上一条语句残留值，或为NULL -
USER()或CURRENT_USER()不能当租户 ID 用：连接池复用、代理用户、共享账号都会让它失效 - 唯一可行路径是放弃视图做租户过滤，改用应用层强制拼
WHERE tenant_id = ?，或用存储过程 +PREPARE/EXECUTE动态构造，但后者无法被 ORM 自然调用，且丢失执行计划缓存
为什么 RLS 比视图更可靠？
因为 RLS 策略绑定在基表上，不是视图上。
- 只要启用了策略，哪怕用户直写
SELECT * FROM orders，数据库也会自动重写为SELECT * FROM orders WHERE tenant_id = current_setting('app.current_tenant_id')::uuid - 视图可被绕过：用户绕开视图、直查基表、用函数查表、甚至用
UNION ALL拼接多个租户数据，全都不拦 - RLS 还支持
WITH CHECK OPTION等效功能（通过USING和WITH CHECK分离读写策略），能拦截非法写入，而视图的WITH CHECK OPTION容易因 ORM 不传tenant_id导致误报失败
最容易被忽略的一点：RLS 启用后，必须对每个租户角色（如 tenant_t123）单独执行 ALTER TABLE orders ENABLE ROW LEVEL SECURITY，否则策略不生效——很多团队只建了策略却忘了这一步，隔离形同虚设。
