不等价。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匹配的库存”的交叉，完全偏离原意。
多列匹配的本质是“联合键匹配”，不是多个独立条件叠加——这个边界一旦模糊，结果就不可控。
