漏加 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_id vs org_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、每个子查询、每处参数绑定，都默认带着租户上下文——少一次检查，就多一分越权风险。