嵌套查询不能实现多租户数据隔离校验，因其无上下文感知能力且不自动注入租户约束；真正有效的是行级安全策略（rls）或会话变量+视图/函数组合，其中rls为数据库级强制、嵌套查询自然继承。
嵌套查询本身不能实现多租户数据隔离校验——它没有上下文感知能力，也不自动注入租户约束。真正在生产环境起作用的，是行级安全策略（RLS）或会话变量 + 视图/函数的组合，而嵌套查询只是其中某一层的执行形态。
为什么嵌套查询不能直接用于租户校验
嵌套查询（如 SELECT * FROM (SELECT ... FROM orders) t WHERE t.tenant_id = 't123'）里的 WHERE 条件是静态写死或由应用传入的，数据库无法区分这个条件是“业务逻辑”还是“安全强制”。一旦有人绕过外层视图或子查询，直接查基表，隔离就失效了。
- 子查询结果集不携带租户上下文，
CURRENT_SETTING('app.tenant_id')在子查询里不会被自动求值（尤其在物化或优化后） - PostgreSQL 可能将外层
WHERE tenant_id = ...下推到内层，也可能因谓词无关性给优化掉——特别是当内层已含tenant_id过滤但未显式声明依赖时 - MySQL 的派生表（derived table）对
@tenant_id的可见性不稳定，连接复用下容易读到上一个租户的值
嵌套查询配合 RLS 才真正安全
如果你必须用嵌套结构（比如报表聚合、窗口计算），唯一靠谱的做法是：先在底层表启用 RLS，再让嵌套查询自然继承该策略。RLS 是数据库级强制，无论查询怎么嵌套、是否走视图、是否用 CTE，都会生效。
- 确保
orders表已启用 RLS：ALTER TABLE orders ENABLE ROW LEVEL SECURITY - 定义策略时用
USING (tenant_id = current_setting('app.current_tenant', true)::uuid)，注意加missing_ok := true防止未设时报错 - 嵌套查询如
SELECT COUNT(*) FROM (SELECT * FROM orders WHERE status = 'paid') t会自动带上 RLS 过滤，无需额外写WHERE tenant_id = ... - 验证方式：
EXPLAIN (ANALYZE, VERBOSE) SELECT * FROM (SELECT * FROM orders) t;，看执行计划里是否出现Row Filter: (tenant_id = ...)
嵌套查询中误用视图导致隔离失效的典型场景
很多人把带租户过滤的视图当“安全外壳”，再在它上面套一层子查询，以为双重保险。实际恰恰相反：视图一旦定义为 CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = current_setting('app.tenant_id')，PostgreSQL 会在创建时尝试解析 current_setting()，大概率报错或缓存成空值；即使侥幸成功，该条件也不会随每次查询重求值。
- 错误写法：
CREATE VIEW v_orders AS SELECT * FROM orders WHERE tenant_id = current_setting('app.tenant_id')→ 视图不可用或返回空 - 正确替代：
CREATE FUNCTION tenant_orders() RETURNS SETOF orders AS $$ SELECT * FROM orders WHERE tenant_id = current_setting('app.current_tenant', true)::uuid; $$ LANGUAGE sql STABLE SECURITY DEFINER;，再用SELECT * FROM tenant_orders()嵌套 - 更推荐：直接在
orders上开 RLS，所有嵌套都透明受控，不用封装视图或函数
最易被忽略的一点：RLS 策略默认只对普通用户生效，超级用户（superuser）绕过所有 RLS。生产环境务必禁用超级用户直连，或用 ALTER DATABASE ... SET row_security = on 全局强制开启——否则嵌套再深也没用。
