不等价。ON中AND决定关联逻辑，保留左表行；WHERE在JOIN后过滤，会筛掉NULL行导致LEFT JOIN退化为INNER JOIN。

ON子句里用AND连多个条件，和WHERE里写等价吗？

不等价。ON中的AND是关联逻辑的一部分，决定哪些行能“拉进来”；WHERE里的条件是在JOIN结果上过滤，会把没匹配上的NULL行也筛掉——尤其LEFT JOIN时，这点非常关键。

常见错误：把本该在ON里的过滤条件挪到WHERE里，导致LEFT JOIN退化成INNER JOIN。

• ON a.id = b.a_id AND b.status = 'active' → 只有status为active的b行参与关联，a表行仍保留（LEFT JOIN下）
• ON a.id = b.a_id WHERE b.status = 'active' → 先全关联再过滤，b为NULL的行被WHERE干掉，LEFT失效

多列匹配时，NULL值会导致什么问题？

当ON条件中任一字段为NULL，整个AND表达式结果为UNKNOWN，该行不会被关联上——SQL的三值逻辑在这里直接起效，不是“跳过”，而是“不满足”。

典型场景：两张表都有可空的业务编码字段（如region_code、dept_code），用ON a.r = b.r AND a.d = b.d时，只要其中一列是NULL，整条记录就断联。

• 解决办法之一：用COALESCE(a.r, '') = COALESCE(b.r, '')统一转空字符串（注意类型兼容）
• 更安全的做法：显式排除NULL，如ON a.r IS NOT NULL AND b.r IS NOT NULL AND a.r = b.r AND ...
• 别依赖IS NULL在ON里做“补位逻辑”，它和等值判断语义不同

性能上，多个AND条件会影响索引使用吗？

会影响，但取决于数据库和索引结构。MySQL/PostgreSQL会尝试用复合索引最左前缀匹配ON中的列顺序；SQL Server对JOIN谓词的索引选择更敏感。

实操建议：

• 确保ON中所有等值列（=）都落在同一张表的复合索引里，且顺序尽量与ON中出现顺序一致
• 避免在ON里对字段做函数操作，比如ON UPPER(a.code) = UPPER(b.code)，会失索引
• 如果条件含范围（>、BETWEEN），它之后的索引列大概率无法用于查找，只可用于过滤

什么时候必须用多个AND，而不是拆成嵌套JOIN？

当匹配逻辑是“同一组字段共同定义一条有效关系”时，必须合并在一个ON里。拆成多个JOIN容易引发笛卡尔积或语义错误。

例如：订单明细要同时匹配商品ID和仓库ID，且二者组合才唯一确定库存记录。

SELECT *
FROM order_item oi
LEFT JOIN inventory inv 
  ON oi.item_id = inv.item_id 
  AND oi.warehouse_id = inv.warehouse_id

如果写成：

FROM order_item oi
LEFT JOIN inventory inv1 ON oi.item_id = inv1.item_id
LEFT JOIN inventory inv2 ON oi.warehouse_id = inv2.warehouse_id

→ 就变成了找“任意item_id匹配的库存”和“任意warehouse_id匹配的库存”的交叉，完全偏离原意。

多列匹配的本质是“联合键匹配”，不是多个独立条件叠加——这个边界一旦模糊，结果就不可控。