视图本身不能实现多租户逻辑隔离，真正起隔离作用的是视图定义中是否包含租户过滤条件及是否强制用于所有访问路径；必须结合行级安全（RLS）或应用层SQL拦截才能确保隔离。
视图本身不能直接实现多租户逻辑隔离，它只是查询封装；真正起隔离作用的是视图定义中是否包含租户过滤条件，以及该视图是否被强制用于所有访问路径。
视图必须带租户字段过滤才具备隔离能力
单纯创建 CREATE VIEW tenant_users AS SELECT * FROM users; 没有任何隔离效果——它等价于全表暴露。要让视图生效，必须在 SELECT 中显式加入租户维度约束：
- 常见写法是硬编码租户ID（仅测试用）：
CREATE VIEW tenant_users AS SELECT * FROM users WHERE tenant_id = 123; - 生产环境应避免硬编码，改用参数化或结合行级安全（RLS）+ 视图组合，否则每个租户都要建一个视图，维护爆炸
- 若底层表无
tenant_id字段，视图无法凭空隔离——必须先完成共享表模式的结构改造
PostgreSQL RLS + 视图才是安全组合
只靠视图容易绕过：应用层若直接查原表、或用 UNION/CTE 拼接，视图就失效。PostgreSQL 的 ROW LEVEL SECURITY 才是兜底机制：
- 先对基础表启用 RLS：
ALTER TABLE users ENABLE ROW LEVEL SECURITY; - 再创建策略，绑定当前会话角色与租户字段：
CREATE POLICY tenant_isolation ON users FOR ALL USING (tenant_id = current_setting('app.tenant_id', true)::bigint); - 此时即使应用误查
users表，PG 也会自动注入过滤条件；视图可简化为CREATE VIEW current_tenant_users AS SELECT * FROM users;，纯粹做语义封装
MyBatis-Plus 或 Kysely 等框架下，视图基本不参与隔离
这类 ORM/Query Builder 的多租户方案本质是 SQL 拦截重写，和数据库视图无关：
-
MyBatis-Plus通过TenantLineHandler在执行前动态追加WHERE tenant_id = ?，不依赖视图 -
Kysely的WithSchemaPlugin是做 Schema 前缀重写（如tenant_123.users），走的是独立 Schema 模式，和视图无交集 - 如果在这些框架里还额外建视图，反而增加一层冗余抽象，且可能干扰拦截逻辑（比如视图嵌套导致 AST 解析失败）
物化视图不适合多租户实时隔离
物化视图（MATERIALIZED VIEW）数据是快照，刷新有延迟，无法满足租户数据实时可见性要求：
- 刷新策略（
REFRESH CONCURRENTLY）需额外权限，且并发刷新时可能阻塞查询 - 每个租户建一个物化视图？存储和刷新开销随租户数线性增长，DBA 会半夜被报警叫醒
- 真正需要的是“每次查询都实时计算+过滤”，不是缓存结果——这正是普通视图 + RLS 的定位
最容易被忽略的一点：视图的 owner 权限决定谁能查它，但不决定查到什么；真正控制数据范围的，永远是查询执行时的会话上下文（role、GUC 变量）和表级策略（RLS）。别把隔离责任错托给视图命名或创建动作本身。
