核心约束是SQL视图静态定义、不支持运行时参数或会话变量；硬编码tenant_id破坏复用性，而current_setting()等函数在MySQL/SQL Server中不被支持，且视图权限无法实现行级隔离。
什么是多租户视图隔离的核心约束
不能靠 CREATE VIEW 自动识别当前租户——SQL 视图是静态定义，不支持运行时参数或会话变量（除非数据库明确支持，如 PostgreSQL 的 current_setting() 或 MySQL 8.0+ 的 @variable，但有严重限制）。硬写死 tenant_id = 123 的视图无法复用，等于没隔离。
PostgreSQL 中用 current_setting() 实现租户感知视图
PostgreSQL 允许在视图定义中调用会话级配置函数，前提是提前设置好租户上下文。这是少数能较干净实现“逻辑视图隔离”的方案。
- 应用层必须在每次连接后执行
SET app.tenant_id = 'abc123'; - 视图里用
WHERE tenant_id = current_setting('app.tenant_id')::uuid（注意类型转换） - 必须给
current_setting()加DEFAULT和异常兜底，否则未设值时查询直接报错：current_setting('app.tenant_id', true)第二个参数启用 silent 模式 - 该方式依赖客户端严格遵守 SET 协议，连接池（如 PgBouncer）若使用事务池模式会丢失会话变量
MySQL 8.0+ 用用户变量 + 视图的危险实践
MySQL 不允许视图中直接引用用户变量（如 @tenant_id），强行写会报错 ERROR 1351 (HY000): View's SELECT contains a variable or parameter。有人绕道用函数封装：
CREATE FUNCTION get_tenant_id() RETURNS CHAR(36) READS SQL DATA DETERMINISTIC BEGIN RETURN @tenant_id; END;
再在视图里调用 WHERE tenant_id = get_tenant_id()。但这存在三个硬伤：
- 函数无法被下推优化，全表扫描不可避免
- @tenant_id 是连接级变量，但 MySQL 连接复用频繁，极易串租户
- 函数不可索引，
tenant_id字段即使有索引也基本失效
真正可靠的做法：不用视图，改用预处理语句或应用层拼接
视图不是为动态过滤设计的。多租户隔离的健壮实现，应把 tenant_id 作为必填参数由应用注入，而非试图让数据库“猜”租户。
- 所有查询走
PREPARE stmt FROM 'SELECT * FROM orders WHERE tenant_id = ? AND status = ?'，用EXECUTE stmt USING @current_tenant, @status - ORM 层统一拦截，在 where 条件自动追加
AND tenant_id = :currentTenant（如 MyBatis 的<sql>片段、Hibernate 的 @Filter） - 如果非要用视图，只用于跨租户报表类场景（如管理员看全部租户汇总），且明确标注为
admin_all_tenants_view，避免业务代码误用
最常被忽略的一点：视图权限控制本身不解决数据隔离——即使用户只能查视图，若视图定义漏了 tenant_id 过滤，照样看到别人数据。隔离的源头永远在 WHERE 条件，不在视图壳子上。
