多列JOIN需用AND连接等值条件，禁用逗号或括号；必须建与ON顺序一致的联合索引；LEFT JOIN中过滤条件应放ON而非WHERE以保左表完整性。
ON 子句里怎么写多列 JOIN 条件
直接用 AND 连接多个等值条件，别用逗号，也别套括号——这是最常写错的地方。
比如想用 user_id 和 tenant_id 一起关联两张表，正确写法是：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id AND o.tenant_id = u.tenant_id
常见错误包括：ON (o.user_id, o.tenant_id) = (u.id, u.tenant_id)（语法不合法）、ON o.user_id = u.id, o.tenant_id = u.tenant_id（逗号分隔在标准 SQL 中非法）。
- 所有字段必须显式写出比较关系，不能省略操作符
- 如果某列可能为
NULL，=会跳过整行匹配；需要IS NOT DISTINCT FROM（PostgreSQL）或改用COALESCE处理，但性能代价大 - MySQL 8.0+、PostgreSQL、SQL Server 都支持这种写法；SQLite 不支持复合条件中的函数或表达式作为 JOIN 键（除非是简单列）
多列 JOIN 时索引为什么没生效
不是建了两个单列索引就行，数据库优化器通常只用其中一个，另一列靠过滤而非索引查找。
必须建**联合索引**，且顺序要和 ON 中字段顺序一致（至少前缀匹配）。例如：
CREATE INDEX idx_orders_user_tenant ON orders(user_id, tenant_id);
如果 ON 是 o.tenant_id = u.tenant_id AND o.user_id = u.id，只要索引最左字段是 tenant_id 就能用上——但多数人按主键习惯先写 user_id，结果反向写了索引，导致失效。
- 联合索引中字段顺序取决于查询中“最常变化”或“选择性更高”的列放前面（如
tenant_id可能比user_id值更少重复） - MySQL 的
EXPLAIN看key_len：如果是单列索引长度，说明只用了第一个字段；翻倍了才表示两列都走索引 - PostgreSQL 要看
Index Cond是否包含全部 JOIN 字段，而不是只看Filter
LEFT JOIN 多列关联后 NULL 行突然变多
问题往往出在 JOIN 条件里混用了 OR 或非等值判断，或者右表有重复组合值。
例如：LEFT JOIN logs l ON l.order_id = o.id AND l.status IN ('success', 'pending') —— 这会导致一条订单匹配多条日志，结果行数爆炸。这不是 JOIN 写法错，而是语义理解偏差。
- 多列等值 JOIN 本身不会增加行数，但一旦加入范围条件、
IN、!=，就退化成笛卡尔积倾向 - 检查右表是否在关联字段上有重复：运行
SELECT user_id, tenant_id, COUNT(*) FROM users GROUP BY user_id, tenant_id HAVING COUNT(*) > 1 - 若需保左表唯一性，考虑用
LATERAL（PostgreSQL）或子查询 +ROW_NUMBER()去重后再 JOIN
WHERE 和 ON 里放多列条件的区别在哪
ON 控制“怎么连”，WHERE 控制“连完怎么筛”。对 LEFT JOIN 来说，这点极其关键。
比如：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id AND o.tenant_id = u.tenant_id WHERE u.status = 'active'
这会把所有 users.status != 'active' 的左连接结果全滤掉，包括 u 为 NULL 的行——实际上变成了内连接效果。
- 要把右表的过滤逻辑留在
ON里才能保持 LEFT 特性：ON ... AND u.status = 'active' - 但注意：如果
u.status是NULL（即没匹配到），NULL = 'active'结果为UNKNOWN，该行仍保留，只是u.*全为NULL - Oracle 对
ON中的非等值条件优化较差，容易放弃使用索引；此时建议拆成子查询提前过滤
多列 JOIN 看似只是加几个 AND，但每列背后都绑着索引策略、NULL 处理、执行计划走向——最容易被忽略的是：你写的顺序，就是优化器找索引的顺序，也是数据分布影响结果的顺序。
