子查询中安全传入租户ID需通过相关子查询将外层tenant_id显式下推至每层子查询，所有含tenant_id的表必须参与等值匹配，禁止独立子查询或运行时函数；UPDATE/DELETE须确保主表与子查询各表均绑定tenant_id；性能问题优先改写为JOIN或使用EXISTS；跨租户汇总必须限定白名单且前置权限校验。
子查询里怎么安全传入租户ID
租户隔离的核心是确保每条查询都自动带上 tenant_id = ? 条件，而不能依赖应用层拼接或手动加 WHERE。子查询本身不接受参数，所以必须靠外层查询把租户上下文“透传”进去——最可靠的方式是把租户 ID 作为查询参数绑定到最外层语句，再通过相关子查询（correlated subquery）逐层下推。
常见错误是写成独立子查询：SELECT * FROM orders WHERE id IN (SELECT order_id FROM logs WHERE type = 'payment')，这完全没绑定租户，数据会跨租户泄露。
正确做法是让子查询引用外层表的 tenant_id 字段：
SELECT o.*
FROM orders o
WHERE o.tenant_id = ?
AND o.status IN (
SELECT DISTINCT status
FROM order_status_history h
WHERE h.order_id = o.id
AND h.tenant_id = o.tenant_id
);- 子查询中
h.tenant_id = o.tenant_id是关键，它把外层租户约束带进去了 - 所有涉及多表关联的子查询，只要表有
tenant_id字段，就必须显式参与等值匹配 - 避免在子查询里用
SELECT * FROM tenants WHERE current_tenant()这类运行时函数——不可控、难测试、多数数据库不支持
UPDATE/DELETE 语句里嵌套子查询怎么防越权
UPDATE 和 DELETE 很容易因子查询漏掉租户条件，导致批量误删其他租户数据。MySQL 和 PostgreSQL 都允许在这些语句里用子查询，但语法限制多，稍不注意就失效。
例如这个写法看似安全，实则危险：DELETE FROM notifications WHERE user_id IN (SELECT id FROM users WHERE role = 'admin') —— 子查询里的 users 表没限定 tenant_id，可能拉出全库管理员。
必须把租户过滤下沉到底层：
DELETE FROM notifications n
WHERE n.tenant_id = ?
AND n.user_id IN (
SELECT u.id
FROM users u
WHERE u.tenant_id = ?
AND u.role = 'admin'
);- UPDATE/DELETE 的主表和子查询中的每张表，都要独立声明
tenant_id = ?或与主表字段对齐 - PostgreSQL 支持
USING语法，可更清晰表达关联：DELETE FROM notifications n USING users u WHERE n.user_id = u.id AND n.tenant_id = u.tenant_id AND n.tenant_id = ? - MySQL 8.0+ 允许在 DELETE 中用 JOIN，但子查询方式兼容性更好，尤其面对老旧 ORM
性能陷阱：相关子查询在大数据量下变慢怎么办
相关子查询（即引用外层列的子查询）本质是“对主表每行执行一次子查询”，当 orders 表有百万行，而子查询又没走索引，就会变成 O(n×m) 复杂度。
典型症状是执行计划里出现 DEPENDENT SUBQUERY 且 rows 扫描数巨大，或者 PostgreSQL 中显示 SubPlan 被反复调用。
- 首要检查子查询里的
WHERE字段是否都有复合索引，例如(tenant_id, order_id)而不只是order_id - 能改写为 JOIN 就优先改写，特别是当子查询只用于过滤存在性时：
EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id AND l.tenant_id = o.tenant_id)比IN更易优化 - 避免在子查询里做聚合或排序——
SELECT MAX(created_at)类操作无法下推租户条件，容易扫全租户数据
跨租户汇总类查询为什么不能直接套子查询
如果业务需要“查看所有租户中订单最多的用户”，这类跨租户统计天然违背隔离原则。此时子查询不是用来隔离，而是用来构造安全边界——你得先明确：这个汇总权限是否真的该存在？谁可以看？
若确需支持，不能靠一个子查询搞定，而要分两步：先用子查询按租户分别算，再用外层聚合收口，且必须限定可访问的租户白名单：
SELECT tenant_id, user_id, cnt
FROM (
SELECT tenant_id, user_id, COUNT(*) AS cnt,
ROW_NUMBER() OVER (PARTITION BY tenant_id ORDER BY COUNT(*) DESC) AS rn
FROM orders
WHERE tenant_id IN ('t-001', 't-002') -- 显式白名单，绝不能用子查询动态查 tenants 表
GROUP BY tenant_id, user_id
) ranked
WHERE rn = 1;- 子查询里禁止出现
SELECT tenant_id FROM tenants WHERE is_active这类动态租户枚举——它会让整个语句脱离租户上下文管控 - 所有跨租户逻辑必须由权限系统前置校验，SQL 层只负责在已授权范围内计算
- 一旦子查询开始读取元数据表（如
tenants、tenant_configs），就要警惕 SQL 注入和权限绕过风险
租户隔离不是加个 WHERE 就完事，子查询是把关人，也是放大器——写错一句 tenant_id 匹配，就可能让隔离形同虚设。
