漏加 tenant_id 会导致跨租户数据泄露，所有嵌套查询、JOIN 和子查询必须显式过滤 tenant_id，优先用 EXISTS 替代 IN，避免 MySQL 5.7 关联子查询性能退化。
WHERE 条件里漏加 tenant_id 就会跨租户查数据
多租户系统里，tenant_id 是最基础的数据隔离锚点。嵌套查询一旦在子查询或外层 WHERE 中漏掉 tenant_id 过滤，就可能把其他租户的记录拉进来——尤其是用 IN、EXISTS 或 JOIN 时，子查询若没显式带上当前租户约束，数据库根本不知道该拦谁。
实操建议：
- 所有嵌套查询的最内层 SELECT，只要涉及业务表（非字典/配置表），都必须包含
WHERE tenant_id = ? - 避免在子查询中用
SELECT * FROM orders这类裸表引用；改成SELECT id FROM orders WHERE tenant_id = ? - 如果子查询结果要被外层多次引用（比如 CTE），记得在 CTE 定义里就过滤
tenant_id，别拖到外层再 filter - 用
EXISTS时，相关子查询的WHERE必须关联外层租户上下文，例如：EXISTS (SELECT 1 FROM invoices i WHERE i.order_id = o.id AND i.tenant_id = o.tenant_id)
JOIN 多表时 tenant_id 分布不一致导致漏数据
常见场景：主表有 tenant_id，但关联的用户表、产品表是全局共享的（无 tenant_id 字段），或者某些历史表用 org_id 替代了 tenant_id。这时候直接 JOIN 会破坏隔离逻辑，要么丢数据，要么错连。
实操建议：
- 确认每张参与 JOIN 的表是否属于租户粒度：共享表（如
users）通常靠tenant_id字段或关联中间表（如tenant_users）来限定范围 - 不要依赖“主表 tenant_id 自动传递”——SQL 不会自动下推，每个表的过滤条件得独立写
- 若存在字段名不统一（如
tenant_idvsorg_code），优先在视图或 DAO 层做映射，不在 SQL 里硬写WHERE org_code = ?混用 - 用
LEFT JOIN时尤其小心：右表若没tenant_id过滤，可能返回空匹配但实际不该出现的租户上下文
子查询返回 NULL 导致 WHERE IN 判定失效
WHERE id IN (SELECT order_id FROM invoices WHERE tenant_id = ?) 看似安全，但如果子查询没结果，整个 IN 表达式会变成 WHERE id IN ()，即恒假——不是报错，而是静默返回空集，容易被当成“没数据”忽略，实则是隔离逻辑崩了。
实操建议：
- 用
EXISTS替代IN更可靠，因为EXISTS对空子查询返回false，语义清晰且不受 NULL 影响 - 若必须用
IN，先确保子查询至少返回一行（比如加UNION SELECT NULL不解决问题，反而更乱；正确做法是检查业务逻辑是否允许空集合） - 在应用层对嵌套查询结果做空值校验不如在 SQL 层堵住源头：把子查询封装成带
tenant_id参数的可复用 CTE，避免手写时遗漏 - PostgreSQL 中可考虑用
ARRAY+@>操作符替代IN，但注意索引支持和参数绑定限制
MySQL 5.7 下关联子查询性能断崖式下降
MySQL 5.7 对含 tenant_id 的关联子查询优化能力弱，特别是当子查询里有 ORDER BY 或 LIMIT 时，容易退化成嵌套循环，租户数据量一上去，查询从毫秒变秒级。
实操建议：
- 避免在子查询里写
ORDER BY ... LIMIT 1做“取最新一条”，改用窗口函数（MySQL 8.0+）或提前物化中间结果 - 给所有租户字段加联合索引，顺序按查询频率排，例如：
(tenant_id, created_at)比单列tenant_id索引更有效 - 用
EXPLAIN看执行计划，重点盯type是否为ALL或index，以及rows是否远超预期 - 如果嵌套层级深（三层以上），拆成应用层两步查：先查主键列表，再用
WHERE id IN (...)批量捞，比纯 SQL 更可控
真正难的不是写对一个嵌套查询，而是保证每次 JOIN、每个子查询、每处参数绑定，都默认带着租户上下文——少一次检查，就多一分越权风险。
