tenant_id 条件必须放在 ON 子句中，否则 LEFT JOIN 会退化为 INNER JOIN，导致左表本应保留的租户无关记录被过滤；同时需加表别名避免字段歧义，并为右表 tenant_id 建索引以保障性能。
LEFT JOIN 多租户查询时，tenant_id 条件该放 ON 还是 WHERE？
必须放在 ON 子句里，否则会丢失主表中本应存在的租户无关记录。比如查所有订单（orders），同时关联租户配置（tenant_configs），但某个订单的 tenant_id 在配置表里还没录入——这时用 WHERE t.tenant_id = 'abc' 会直接过滤掉这条订单；而 ON t.tenant_id = o.tenant_id AND t.tenant_id = 'abc' 才能保留订单行，只让配置字段为 NULL。
常见错误现象：LEFT JOIN 后结果行数比左表还少，或预期的 NULL 关联行消失。
-
ON中写租户过滤：保证左表完整性，适合“查主数据 + 可选租户上下文”场景 -
WHERE中写租户过滤：实际退化为INNER JOIN，仅适用于强制要求关联存在租户元数据的逻辑 - 若右表本身有租户字段且需多条件匹配（如
status = 'active'），所有租户相关条件都得塞进ON，避免提前剪枝
跨租户 LEFT JOIN 查询报错 “column tenant_id is ambiguous” 怎么办？
因为左右表都有 tenant_id，SQL 解析器无法判断你指哪一个。不加表别名直接引用必然失败。
实操建议：
- 给每个表显式加短别名，例如
FROM orders o LEFT JOIN tenant_configs t ON t.tenant_id = o.tenant_id - 所有字段引用统一用
别名.字段名，包括SELECT和WHERE/ON子句 - 如果查询涉及三张以上租户表（如
orders、products、users），建议在建表时统一租户字段前缀（如tenant_id而非混用org_id、account_id），减少歧义
LEFT JOIN 多租户查询性能突然变差，可能卡在哪？
最常被忽略的是右表缺少 tenant_id 字段的索引。即使左表 orders.tenant_id 有索引，若 tenant_configs.tenant_id 没索引，JOIN 过程就得全表扫描右表，租户数一多就明显拖慢。
检查与优化步骤：
- 用
EXPLAIN看执行计划，确认右表是否走了tenant_id索引（注意不是主键索引，而是单独为tenant_id建的索引） - 右表复合索引要按
tenant_id开头，例如INDEX idx_tenant_status (tenant_id, status)，才能支撑ON t.tenant_id = o.tenant_id AND t.status = 'active' - 避免在
ON条件里对租户字段做函数操作，比如ON t.tenant_id = UPPER(o.tenant_id)，这会让索引失效
用 LEFT JOIN 查租户隔离数据，为什么 NULL 值没被正确过滤？
因为 LEFT JOIN 本身不负责租户隔离，它只负责关联逻辑；隔离靠的是你在 ON 或 WHERE 中写的租户条件。如果漏写或写错，就会查出其他租户的数据。
典型疏漏点：
- 忘记在
ON中加入租户等值条件，只写了业务字段（如ON t.config_key = o.type），导致右表所有租户记录都参与关联 - 租户字段类型不一致，比如左表是
VARCHAR(32)，右表是CHAR(36)，隐式转换可能导致索引失效或匹配失败 - 租户 ID 存在大小写混用（如 'ABC' 和 'abc'），而数据库排序规则（collation）又不区分大小写，导致意外匹配
真正起隔离作用的永远是那个明确写出的 tenant_id = ? 条件，LEFT JOIN 只是它的载体。别指望 JOIN 类型自己扛隔离责任。
