子查询不能替代租户隔离，必须在所有查询路径（主查询、子查询、JOIN、IN、EXISTS）中显式添加tenant_id过滤条件；相关子查询不会自动继承外层租户条件；性能上需确保tenant_id索引不被函数或类型转换破坏。
子查询不能直接替代租户隔离，必须配合 WHERE 过滤
子查询本身不提供租户隔离能力。它只是数据检索逻辑的一部分，如果主查询或子查询中漏掉 tenant_id 条件，哪怕嵌套再深，也会跨租户泄露数据。常见错误是写了一个看似“封装好”的子查询（比如统计某类订单数），但没把 tenant_id = ? 同时加在子查询和外层查询里。
正确做法是：所有涉及租户表的查询路径——包括 JOIN 的表、IN 子查询的源表、EXISTS 的子句——都必须显式带上租户过滤条件。例如：
SELECT * FROM orders o
WHERE o.tenant_id = 't_123'
AND o.status IN (
SELECT status FROM order_status_ref r
WHERE r.tenant_id = 't_123' AND r.is_active = true
);注意两个 tenant_id = 't_123' 缺一不可。漏掉子查询里的这一行，order_status_ref 就会返回全量状态，可能让租户看到不该见的业务规则。
关联子查询比独立子查询更易出错
当子查询引用了外层表字段（即相关子查询），容易误以为外层的 tenant_id 过滤会自动“透传”进去。实际上不会。数据库只保证外层 WHERE 生效，子查询仍需自己约束租户上下文。
典型陷阱场景：
- 用
EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id)检查日志是否存在，但忘了加l.tenant_id = o.tenant_id - 用
o.total_amount > (SELECT AVG(total_amount) FROM orders o2 WHERE o2.created_at > '2024-01-01')做横向对比，子查询没限定租户，结果变成拿全量平均值跟当前租户比
这类写法在单租户环境能跑通，上线多租户后立刻出问题。建议把相关子查询里的租户条件写成 l.tenant_id = o.tenant_id 而非硬编码，避免后续改租户键名时漏同步。
性能隐患：子查询可能绕过租户索引
即使语法上写了 tenant_id，某些数据库优化器在复杂子查询中会放弃使用复合索引（如 (tenant_id, created_at)），转而走全表扫描。特别是当子查询含函数、类型转换或 OR 条件时。
验证方式很简单：对关键查询执行 EXPLAIN，检查是否命中 tenant_id 索引。常见诱因有：
- 子查询里写
WHERE tenant_id::text = ?（隐式类型转换） - 用
IN (SELECT tenant_id FROM temp_tenant_list)引入中间表，且该表无索引 - 子查询含
ORDER BY ... LIMIT 1但没加tenant_id在 ORDER BY 前置条件中
解决思路不是禁用子查询，而是把租户条件尽量“推”到最内层，并确保索引字段不被函数包裹。例如把 created_at::date = current_date 改成 created_at >= current_date AND created_at 。
视图 + 子查询组合要格外小心
有人会建一个带子查询的视图（如 v_user_orders_with_count），然后在应用里直接 SELECT * FROM v_user_orders_with_count WHERE tenant_id = ?。这很危险——因为视图定义里若没固化租户条件，外部 WHERE 无法下推到子查询内部。
PostgreSQL 会尝试下推，但 MySQL 8.0 之前基本不支持；即使支持，也受限于子查询是否可合并（mergeable）。稳妥做法只有两个：
- 视图定义中直接写死
WHERE tenant_id = current_setting('app.tenant_id')（需配合连接层设置 session variable） - 根本不用视图，把租户过滤逻辑收口到 ORM 层或存储过程，由统一 SQL 构造器注入
tenant_id
最常被忽略的一点：数据库用户权限 ≠ 租户隔离。即使给每个租户配了独立 DB 用户，只要 SQL 里没写 tenant_id，照样能通过子查询跨查。租户边界永远在 WHERE 条件里，不在账号里。
