null = null返回unknown导致join不匹配，因on只保留true行；可用is not distinct from、coalesce或or分支处理，且右表条件须放on而非where。
JOIN条件里a.id = b.id遇到NULL为什么不匹配
因为NULL = NULL在SQL三值逻辑中返回UNKNOWN，而JOIN的ON只保留求值为TRUE的行。UNKNOWN被当作“不满足”，所以两边都是NULL的行直接被跳过——这不是bug，是标准行为。
常见错误现象包括：
-
LEFT JOIN后右表字段全为NULL，但业务上明明该有“未知客户”这类语义关联 - ETL清洗后外键字段留空，导致本应归入“未指定分类”的记录彻底丢失
- 用
WHERE b.status = 'active'过滤后，左表行数骤减，实际退化成INNER JOIN
PostgreSQL/MySQL 8.0.16+ 用IS NOT DISTINCT FROM
这是最接近语义直觉的写法，把NULL当作一个可比较的“值”：NULL和NULL判为TRUE，非NULL值之间仍按常规等值判断。
正确用法：
- 只能用于列对列比较，如
o.customer_id IS NOT DISTINCT FROM c.id - 不能写成函数调用：
IS_NOT_DISTINCT_FROM(o.customer_id, c.id)（语法错误） - 避免裸写
a.col IS NOT DISTINCT FROM NULL，除非你明确要捕获所有a.col为NULL的行
示例（PostgreSQL）：
SELECT * FROM orders o JOIN customers c ON o.customer_id IS NOT DISTINCT FROM c.id;
通用兼容方案：COALESCE兜底或OR显式分支
当数据库不支持IS NOT DISTINCT FROM（如SQL Server、Oracle），必须手动绕过三值逻辑。
COALESCE方案（推荐）：
- 选一个业务中绝对不出现的替代值，如
-999999、'__NULL__' - 写法：
ON COALESCE(a.id, -999999) = COALESCE(b.id, -999999) - 注意：若原字段本身可能存这个兜底值，结果会误匹配
OR分支方案（慎用）：
- 写法：
ON (a.id = b.id) OR (a.id IS NULL AND b.id IS NULL) - 缺点：多数优化器无法下推索引，大表JOIN时性能明显下降
- 适合小表或临时分析，别放在线上高频查询里
LEFT JOIN中右表条件必须进ON，不能放WHERE
这是最容易被忽略的执行顺序陷阱。JOIN先按ON完成连接，再用WHERE全局过滤。一旦WHERE里写了右表字段条件，所有右表为NULL的行（即没匹配上的左表行）就被干掉了。
错误写法：
SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id WHERE u.status = 'active'; -- 实际等效于 INNER JOIN
正确写法：
- 把业务条件塞进
ON：ON o.user_id = u.id AND u.status = 'active' - 这样左表所有订单都保留，仅当
u.status不满足时，u.*字段为NULL - 如果还要区分“有用户但状态不对”和“根本没用户”，得靠
CASE WHEN u.id IS NULL THEN ...后续判断
真正麻烦的不是语法怎么写，而是得时刻分清：你是在定义“哪些行能连上”，还是在定义“连完之后留哪些”。前者是ON的事，后者才是WHERE的职责——一旦混淆，NULL就变成隐形过滤器。
