NULL在ON条件中永不匹配，因其比较结果为UNKNOWN而JOIN只认TRUE；需用COALESCE、CASE或NULL安全操作符（如、IS NOT DISTINCT FROM）显式处理。
NULL 在 ON 条件中永远不匹配
SQL 中的 NULL 表示“未知”，不是值，也不是空字符串或零。因此，任何涉及 NULL 的等值比较（如 a.col = b.col）只要其中一边是 NULL，整个表达式就返回 UNKNOWN，而 JOIN 的 ON 条件只接受 TRUE 才算匹配——UNKNOWN 和 FALSE 都被当作“不匹配”。这意味着：
-
INNER JOIN会直接丢弃含NULL的行（哪怕两边都是NULL，也不匹配） -
LEFT JOIN中左表该行保留，但右表对应列全为NULL（因为没匹配上） - 即使你写
ON a.id = b.id OR (a.id IS NULL AND b.id IS NULL)，多数数据库（如 SQL Server、PostgreSQL、MySQL 8.0+）仍不会自动启用这种逻辑——它需要显式写出，且可能破坏索引下推
想让 NULL 和 NULL 匹配？必须显式重写条件
默认行为无法改变，但你可以绕过它。常见做法是用 COALESCE 或 CASE 把 NULL 转成一个确定的占位值（前提是该值在业务数据中真实不会出现）：
SELECT * FROM orders o LEFT JOIN customers c ON COALESCE(o.customer_id, -1) = COALESCE(c.id, -1);
这个技巧有效，但要注意：
-
-1必须确保不在customer.id或orders.customer_id中真实存在，否则会造成错误关联 - 使用
COALESCE后，数据库通常无法走索引（尤其当字段本身有索引时），性能可能下降 - 更安全的写法是用
CASE+IS NULL组合判断，例如：ON (o.customer_id = c.id) OR (o.customer_id IS NULL AND c.id IS NULL)
LEFT JOIN 后 WHERE 列 IS NULL 的陷阱
这是最常踩的坑：你以为在找“左表有、右表无”的记录，但如果右表连接字段本身允许 NULL，那么 WHERE c.id IS NULL 会同时捕获两种情况：
- 右表真没匹配到（预期结果）
- 右表匹配到了，但
c.id本身就是NULL（非预期，且难以区分）
解决办法是把过滤提前到 ON 子句中，排除掉右表无效的 NULL 值：
SELECT o.order_no FROM orders o LEFT JOIN customers c ON o.customer_id = c.id AND c.id IS NOT NULL;
这样，c.id IS NULL 在 WHERE 中就只代表“没匹配”，不再混淆。
不同数据库对 NULL 处理的细微差异
虽然标准 SQL 规定 NULL = NULL 为 UNKNOWN，但部分场景下引擎行为略有出入：
- Hive / Spark SQL：支持
NULL SAFE EQUALS（即），a.id b.id可让NULL NULL返回TRUE - PostgreSQL：提供
IS NOT DISTINCT FROM，语义等价于 - SQL Server：不支持
，必须用IS NULL显式判断 - MySQL：5.7+ 支持
，但注意它和=的优先级不同，建议加括号
跨平台迁移时，别依赖 ，优先用可移植的 COALESCE 或 CASE 方案。
