不能直接用CREATE VIEW做多租户隔离，因为视图定义静态、不支持动态租户上下文绑定；硬编码破坏复用性，current_setting等函数在MySQL/SQL Server中不被支持；视图权限无法实现行级约束，必须依赖RLS或应用层强制过滤。
为什么不能直接用 CREATE VIEW 做多租户隔离
通用视图本身不支持动态绑定租户上下文，CREATE VIEW 定义是静态的，无法自动识别当前请求属于哪个租户。硬编码 WHERE tenant_id = 123 会彻底破坏复用性；而用 WHERE tenant_id = CURRENT_SETTING('app.tenant_id') 这类方式在 PostgreSQL 中看似可行，但 MySQL、SQL Server 等主流数据库根本不支持运行时参数化视图——一执行就报错 Unknown column 'CURRENT_SETTING' 或类似语法错误。
更关键的是，视图权限控制粒度太粗：即使你绕过语法限制造出“带租户过滤的视图”，只要用户有该视图的 SELECT 权限，就能查到所有租户数据（因为视图定义里没做行级约束），除非额外配行级安全策略（RLS），但这已超出视图能力范围。
PostgreSQL 中用 RLS + 视图组合实现安全隔离
真正可行的路径是：视图只负责字段抽象和逻辑简化，把租户隔离交给行级安全策略（RLS）来兜底。这样既保持视图通用性，又确保数据不越界。
- 先建一个不含租户过滤的通用视图：
CREATE VIEW v_orders AS SELECT id, user_id, amount, created_at FROM orders;
- 再为
orders表启用 RLS，并添加策略：ALTER TABLE orders ENABLE ROW LEVEL SECURITY;<br>CREATE POLICY tenant_isolation_policy ON orders<br> USING (tenant_id = current_setting('app.tenant_id', true)::bigint); - 应用层每次查询前必须设置变量：
SET app.tenant_id = '456';（注意：需连接池支持 session 变量透传） - 此时
SELECT * FROM v_orders;自动只返回租户 456 的订单，且其他租户数据完全不可见
⚠️ 容易踩的坑：current_setting 第二个参数设为 false 会导致找不到变量时直接报错中断查询；设为 true 返回 NULL，而 tenant_id = NULL 永远为 false，结果是查不到任何数据——这反而成了安全默认行为，但调试时容易误以为策略没生效。
MySQL 和 SQL Server 怎么办：用存储过程或应用层拼接
MySQL 不支持 RLS，SQL Server 虽有 RLS 但要求企业版且策略绑定到具体用户，无法适配应用级租户。这时视图只能退化为“字段别名模板”，真实过滤必须由上层处理：
- 创建无条件视图仅用于统一字段输出：
CREATE VIEW v_orders AS SELECT id, user_id, amount, created_at, tenant_id FROM orders;
- 所有查询必须显式加租户条件：
SELECT * FROM v_orders WHERE tenant_id = ?（? 由应用传入） - 或者封装成存储过程：
CREATE PROCEDURE get_tenant_orders(IN t_id BIGINT)<br>BEGIN<br> SELECT id, user_id, amount, created_at FROM orders WHERE tenant_id = t_id;<br>END;
——但这就不是“视图”了，而是接口契约转移
性能提示：如果租户字段没建索引，WHERE tenant_id = ? 会导致全表扫描。务必确认 tenant_id 是联合索引的最左前缀（例如 (tenant_id, created_at)），否则高并发下 I/O 直接拉满。
跨租户管理场景下如何临时绕过隔离
运维或 BI 报表需要查多个租户数据时，RLS 会拦住一切访问。PostgreSQL 提供 bypassrls 权限，但绝不能直接授给应用账号——应单独建只读管理员角色：
CREATE ROLE reporting_user NOINHERIT;GRANT SELECT ON v_orders TO reporting_user;-
ALTER TABLE orders FORCE ROW LEVEL SECURITY;（强制所有访问走策略，包括 superuser） -
ALTER ROLE reporting_user BYPASSRLS;（仅该角色可绕过）
这个设计的关键在于：绕过权限必须显式切换角色（SET ROLE reporting_user），不能靠应用自动触发。否则任意 SQL 注入都可能升级为跨租户数据泄露。
真正麻烦的从来不是怎么写视图，而是租户上下文如何从 HTTP 请求头/Token 稳定、低延迟地注入到每个数据库连接的 session 变量中——这里一旦出错，隔离就形同虚设。
