单纯用视图无法保证租户数据隔离，因其仅为预定义SELECT语句，无运行时校验；用户可绕过视图直查基表，且视图不强制绑定tenant_id动态过滤，导致隔离失效。

SQL视图本身不能直接实现行级权限控制，它只是查询的封装；真正的隔离必须依赖数据库原生的行级安全策略（RLS）或应用层过滤，视图仅可作为辅助手段配合使用。

为什么单纯用视图无法保证租户数据隔离

视图本质是预定义的 SELECT 语句，不带执行时校验逻辑。如果用户绕过视图直查基表，或视图未强制绑定租户字段过滤，就完全失效。

• 常见错误现象：SELECT * FROM tenant_orders_view 返回了所有租户订单，因为视图定义里漏写了 WHERE tenant_id = current_setting('app.tenant_id') 这类动态条件
• 使用场景：PostgreSQL 中想复用同一套 SQL 逻辑给不同租户，但又不想每个查询都手写 AND tenant_id = ?
• 性能影响：视图若含复杂 JOIN 或未在 tenant_id 上建索引，会导致全表扫描，尤其基表数据量大时响应明显变慢

PostgreSQL 中配合 RLS 实现可靠隔离（推荐路径）

视图应退居为“只读接口”，核心隔离交由 RLS 策略管理，确保即使直查基表也安全。

• 先在基表启用 RLS：ALTER TABLE orders ENABLE ROW LEVEL SECURITY
• 创建策略强制租户过滤：CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
• 视图只需简化字段或做轻量转换，例如：CREATE VIEW tenant_orders AS SELECT id, amount, created_at FROM orders（不加 WHERE）
• 连接时必须设置会话变量：SET app.tenant_id = 'a1b2c3d4-...'，否则 RLS 策略中 current_setting 返回 NULL，导致无数据可见

MySQL / SQL Server 用户的替代方案

这些数据库没有原生 RLS，只能靠视图 + 应用层约束，风险更高，需更严格管控。

• MySQL 视图无法引用变量，只能硬编码租户 ID —— 这意味着每个租户需单独建一个视图，如 tenant_a_orders、tenant_b_orders，运维成本陡增
• SQL Server 可用 SESSION_CONTEXT() 配合内联表值函数（TVF），但 TVF 无法被所有 ORM 正确识别，且必须显式传参，容易遗漏
• 关键限制：MySQL 视图不支持子查询中的 SET @var，也不能用 USER() 解析租户标识，基本无法动态化
• 必须禁止普通用户对基表的 SELECT 权限，只授予视图权限，并定期审计 SHOW GRANTS FOR 'user'@'%'

最容易被忽略的三个细节

多数人卡在这几步上，不是不会写视图，而是没意识到底层机制的耦合点。

• RLS 策略默认对 postgres 超级用户无效 —— 测试时用超级用户连，永远看到全部数据，误以为策略没生效
• current_setting() 在 PostgreSQL 中返回 text，和 tenant_id uuid 类型不匹配时会静默失败，必须显式强转
• 视图嵌套（视图 A 基于视图 B）在开启 RLS 后可能触发多次策略检查，某些版本存在性能回退，建议扁平化设计