动态视图中无法直接用CURRENT_USER获取业务租户身份，应依赖会话变量：PostgreSQL用current_setting('app.current_tenant_id', true)，SQL Server用SESSION_CONTEXT()，MySQL用@current_tenant_id，且须由应用层在每次查询前显式设置。
动态视图里怎么拿到当前用户身份？
SQL 标准不定义“当前用户”在视图内的上下文，所以不能直接写 CURRENT_USER 或 SESSION_USER 就完事——多数数据库（如 PostgreSQL、SQL Server）虽支持这些函数，但它们在物化视图或某些查询重写场景下可能被提前求值，导致租户过滤失效。
真正可靠的方式是依赖数据库会话级变量或应用层透传的标识：
- PostgreSQL：用
current_setting('app.current_tenant_id', true)，前提是应用在连接后执行了SET app.current_tenant_id = 't123' - SQL Server：用
SESSION_CONTEXT(N'tenant_id')，需应用调用sp_set_session_context设置 - MySQL 8.0+：可用用户变量
@current_tenant_id，但注意它不跨语句持久，得每条查询前 SET 一次，不适合视图封装
别用 CURRENT_ROLE 或 USER 模拟租户——角色名不是租户 ID，且权限变更时逻辑就断了。
CREATE VIEW 里嵌套 tenant_id 过滤安全吗？
不安全。静态视图定义里硬编码 WHERE tenant_id = 't123' 或引用函数但没绑定会话上下文，会导致所有用户查到同一份数据，或直接报错（比如函数不存在于视图创建者 schema）。
正确做法是把租户条件完全交给运行时解析：
- PostgreSQL 示例：
CREATE VIEW user_orders AS SELECT * FROM orders WHERE tenant_id = current_setting('app.current_tenant_id', true)::uuid; - 必须确保返回值类型匹配字段类型（如
::uuid），否则运行时报类型转换错误 - 视图定义中避免子查询包裹过滤逻辑（如
WHERE tenant_id IN (SELECT ...)），这会让优化器无法下推条件，全表扫描风险高
注意：这种视图不能被物化（MATERIALIZED VIEW 不支持 volatile 函数），否则刷新失败。
应用连上数据库后忘记 SET tenant_id 会怎样？
后果很直接：current_setting(..., true) 返回 NULL，整张视图查出来零条记录——用户看不到任何数据，但不会报错，排查起来容易误判为“数据丢了”或“前端没渲染”。
防御性写法有两条路：
- 在视图里加非空校验：
WHERE tenant_id = COALESCE(nullif(current_setting('app.current_tenant_id', true), ''), 'INVALID_TENANT')::uuid，然后配合监控告警拦截'INVALID_TENANT'查询 - 更推荐：在应用连接池初始化阶段强制执行 SET，并在 DAO 层做前置检查，比如 MyBatis 的
Interceptor或 Spring 的DataSourceProxy拦截未设租户的查询
别指望数据库触发器或默认值兜底——视图是只读的，且租户隔离必须发生在查询入口，晚一步就漏数据。
PostgreSQL vs SQL Server 动态视图性能差异在哪？
核心区别在函数稳定性标记和查询重写能力：
- PostgreSQL 要求
current_setting这类函数标为VOLATILE（它确实是），所以优化器知道不能提前计算，每次都会调用；但代价是无法利用tenant_id字段上的索引做 Index Only Scan，除非你建表达式索引：CREATE INDEX idx_orders_tenant ON orders ((current_setting('app.current_tenant_id', true)::uuid))—— 这种索引无效，别试 - SQL Server 的
SESSION_CONTEXT是内建轻量机制，配合参数化查询计划复用较好，但要注意：如果不同租户数据量差异极大（比如一个租户占 90% 行数），SQL Server 可能复用低效的执行计划，得加OPTION (RECOMPILE)强制重编译
真正影响性能的不是视图本身，而是租户字段是否在关键查询路径上有索引，以及应用是否在事务开始时就 SET 好上下文——延迟设置会导致后续多条语句反复解析函数，放大开销。
