子查询不能直接实现多租户隔离，必须在每层子查询中显式添加tenant_id条件，否则会导致跨租户数据泄露；使用with子句提前限定租户范围更安全，但关联表仍需独立校验tenant_id。
子查询不能直接实现多租户隔离
SQL子查询本身不带租户上下文，SELECT * FROM orders WHERE user_id IN (SELECT id FROM users) 这类写法不会自动过滤租户数据。如果没显式加租户条件，子查询结果可能跨租户泄露——比如查到其他租户的用户ID，进而拉出不该看的订单。
必须在每层子查询里都带上租_id条件
多租户场景下，子查询不是“嵌套完就完事”，而是每一层都要独立校验租户归属。常见错误是只在外层加 tenant_id = ?，但子查询里漏了：
-
SELECT name FROM departments WHERE id IN (SELECT dept_id FROM employees WHERE tenant_id = ?)✅ 正确：子查询有tenant_id -
SELECT name FROM departments WHERE id IN (SELECT dept_id FROM employees)❌ 危险：子查询没租户过滤，可能命中其他租户的部门 - 关联子查询也要注意：例如
EXISTS (SELECT 1 FROM logs l WHERE l.order_id = o.id AND l.tenant_id = o.tenant_id)—— 这里l.tenant_id = o.tenant_id是关键，不能只写l.tenant_id = ?（否则外层o可能来自不同租户）
用 WITH 子句提前限定租户范围更安全
把租户过滤提到最外层公共表达式里，能减少重复写条件、降低漏写风险。尤其当子查询嵌套深或复用多次时：
WITH my_tenant_users AS ( SELECT id, name FROM users WHERE tenant_id = ? ) SELECT u.name, COUNT(o.id) FROM my_tenant_users u LEFT JOIN orders o ON o.user_id = u.id AND o.tenant_id = ? GROUP BY u.id;
这里 my_tenant_users 已经锁定租户，后续所有引用都天然隔离；但注意：orders 表的 tenant_id 仍需显式校验，不能依赖外键或业务假设。
警惕子查询返回 NULL 或空集导致逻辑错乱
多租户下，某租户可能没有匹配的子查询数据（比如没创建部门），这时 IN (SELECT ...) 会变成 IN (NULL)，整个条件恒为 false——结果不是“查不到”，而是“查得全空”。更稳妥的做法是：
- 用
EXISTS替代IN，避免 NULL 陷阱：WHERE EXISTS (SELECT 1 FROM departments d WHERE d.id = o.dept_id AND d.tenant_id = ?) - 若必须用
IN，先确保子查询结果非空，或用COALESCE包裹：WHERE o.dept_id IN (SELECT COALESCE(id, -1) FROM departments WHERE tenant_id = ?) - ORM 框架自动生成子查询时，检查它是否透传了租户参数——很多框架（如 MyBatis 动态 SQL、Hibernate @Filter）默认不处理子查询里的租户字段
真正难的不是写对一条语句，而是让所有路径（包括异常分支、默认值、缓存回填、批量更新）都保持租户边界清晰。一个漏掉的 tenant_id 条件，就等于开了个后门。
