单纯用视图无法保证租户数据隔离，因其仅为预定义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 后可能触发多次策略检查，某些版本存在性能回退，建议扁平化设计
