结论：SQL里没有原生的“NULL安全JOIN条件”，必须手动处理NULL匹配逻辑，否则ON子句中col1 = col2在任一列为NULL时永远返回UNKNOWN（非TRUE），导致行不匹配而被丢弃；应使用IS NOT DISTINCT FROM（PostgreSQL等支持）或显式OR逻辑(a.id = b.id) OR (a.id IS NULL AND b.id IS NULL)，且必须写在ON中，不可移至WHERE。
直接说结论：SQL里没有原生的“NULL安全JOIN条件”，必须手动处理NULL匹配逻辑，否则ON子句中col1 = col2在任一列为NULL时永远返回FALSE，导致行被丢弃。
为什么ON a.id = b.id在NULL时失效
SQL标准规定，任何与NULL的等值比较（包括=）结果都是UNKNOWN，而JOIN的ON条件只接受TRUE——UNKNOWN和FALSE效果一样：不连接。
常见错误现象：LEFT JOIN后发现本该匹配的行在右表为NULL，但实际结果里整行消失（其实是没匹配上，不是右表字段为NULL）。
实操建议：
- 用
IS NOT DISTINCT FROM（PostgreSQL、SQL Server 2022+、Trino支持）——它把NULL = NULL视为TRUE - 用显式逻辑组合：
(a.id = b.id) OR (a.id IS NULL AND b.id IS NULL) - 避免用
COALESCE(a.id, -1) = COALESCE(b.id, -1)——若列本身可能含-1，会引发误匹配
IS NOT DISTINCT FROM的兼容性陷阱
这个操作符语义清晰，但不是所有数据库都支持。MySQL、SQLite、旧版SQL Server完全不识别，执行会报错Unknown operator 'IS NOT DISTINCT FROM'或语法错误。
使用场景：当你确认目标数据库支持（比如明确用PostgreSQL 8.3+），它是最简洁可靠的写法。
实操建议：
- PostgreSQL：直接写
ON a.id IS NOT DISTINCT FROM b.id - MySQL：只能退回到
OR写法，且注意括号优先级：ON (a.id = b.id) OR (a.id IS NULL AND b.id IS NULL) - 如果JOIN字段是字符串，还要考虑空字符串
''和NULL是否应视为等价——IS NOT DISTINCT FROM不合并它们，需额外判断
LEFT JOIN中NULL安全匹配的典型误写
有人试图用WHERE b.id IS NULL OR a.id = b.id补救，这是错的：它把过滤逻辑移到了WHERE，会导致LEFT JOIN退化成INNER JOIN效果（因为WHERE会筛掉右表无匹配的行）。
性能影响：显式OR条件可能让优化器放弃索引，尤其当字段无NOT NULL约束时；而IS NOT DISTINCT FROM在支持的引擎中通常能走索引。
实操建议：
- NULL安全逻辑必须严格写在
ON子句内 - 对高频JOIN字段，加
NOT NULL约束比在SQL里反复处理NULL更治本 - 如果业务上NULL表示“未知”，而你又需要把它当作一个有效分类来关联（比如归入“未指定客户”组），那就该用外键+维度表，而不是在JOIN里硬匹配NULL
真正麻烦的从来不是怎么写那个OR，而是得时刻记住：只要列允许NULL，每次写ON就得多看一眼——漏掉一次，数据就少一片，还很难排查。
