很多人第一次遇到这个问题，都是在排查“明明两边都有数据，为什么 JOIN 结果就是对不上”。根源通常不在表里有没有值，而在于关联字段里出现了 NULL，而你仍然按普通等值比较来写。下面就按实际排查顺序，先解释为什么 = 不生效，再看不同数据库下更稳妥的写法，以及哪些看起来省事的方案其实容易出错。
为什么 ON 里用 =，两边都是 NULL 也不会匹配
关键原因是：NULL = NULL 返回的不是 TRUE，而是 UNKNOWN。而 JOIN 只会保留 ON 条件求值为 TRUE 的行，所以 UNKNOWN 会和 FALSE 一样，被当成不匹配处理。
这不是数据库异常，而是 SQL 三值逻辑的正常行为。只要关联条件里有字段可能为 NULL，就不能默认把它当成普通值去比较。
实际查询里，常见表现通常有两种：
INNER JOIN结果比预期少，漏掉了本该关联上的记录。比如用户表和订单表都按ref_id关联，双方这个字段都为NULL，但结果里并不会连上。LEFT JOIN后右表字段全部变成NULL，看起来像右表没数据，实际上是关联条件根本没有命中。
如果你遇到的是这类“数据明明在，结果却没连上”的问题，第一步就该回头检查 ON 子句中是否包含了可能为 NULL 的字段。
PostgreSQL / MySQL 8.0.16+：优先用 IS NOT DISTINCT FROM
如果数据库支持，最直接的做法是使用 IS NOT DISTINCT FROM。它就是为 NULL 安全比较准备的，语义可以理解为“值相等，或者两边同为 NULL”。
基本写法如下：
ON a.id IS NOT DISTINCT FROM b.id这种写法的优点很明确：语义直接、可读性高，也比手写一长串 OR 条件更不容易出错。部分数据库在优化阶段也更容易识别这种比较方式，有机会比手写分支拿到更好的执行计划。
实操时需要注意几件事：
- PostgreSQL 可以直接使用：
ON a.id IS NOT DISTINCT FROM b.id - MySQL 8.0.16+ 支持该写法，但某些版本在
JOIN场景里可能出现优化限制，最好先用EXPLAIN检查执行计划 - 如果是多字段联合关联，要对每个字段分别写条件，不能用一个笼统的兜底逻辑替代
例如：
ON a.id IS NOT DISTINCT FROM b.id
AND a.name IS NOT DISTINCT FROM b.name这里的重点是“逐字段处理”。因为联合关联要求每个键位都按同样的 NULL 语义比较，少写一个字段，或者只在最后补一个 OR，都会让匹配结果偏离预期。
通用兼容写法：显式展开 OR 分支
如果目标数据库不支持 IS NOT DISTINCT FROM，比如一些旧版本 SQL Server、Oracle 场景，就需要手动把“普通相等”和“同为 NULL”两种情况都写出来。
典型写法如下：
ON (a.id = b.id OR (a.id IS NULL AND b.id IS NULL))
AND (a.code = b.code OR (a.code IS NULL AND b.code IS NULL))这种方式最重要的原则，是每个参与 JOIN 的字段都要独立展开，不能把多个字段的 NULL 逻辑混在一起。
例如下面这种写法就有问题：
ON a.id = b.id OR (a.id IS NULL AND b.id IS NULL AND a.code = b.code)它的问题不只是“不够工整”，而是语义本身已经变了。你把一部分字段的判断塞进了某个分支里，最终得到的不是“每个字段都做 NULL 安全比较”，而是另一套混合条件，结果很容易误匹配或漏匹配。
此外，这种显式 OR 分支虽然兼容性最好，但性能往往最难看。原因在于它通常不利于索引使用，数据量一大，执行代价会明显上升。因此更稳妥的做法是：
- 尽量先用
WHERE缩小数据范围 - 必要时按时间段、主键范围等方式分块执行
- 上线前确认真实执行计划，而不是只看语法是否正确
COALESCE 看起来简单，但风险最多
很多人会写成下面这样：
COALESCE(a.id, -1) = COALESCE(b.id, -1)从结果上看，这确实能把两边都是 NULL 的情况转成可比较的值，但它的问题也最集中，稍不注意就会埋下隐患。
首先要确认兜底值是否绝对安全。比如你选了 -1，就必须确保这个值在业务里永远不会出现，而且不只是当前主表主键从 1 开始这么简单，还要检查外键字段、历史迁移数据、ETL 中间态，是否可能写入过这个值。一旦真实数据里出现相同兜底值，就会把原本不该匹配的记录误连起来。
其次，COALESCE 包裹字段后，通常会影响索引利用。原本建在 a.id 上的索引，面对 COALESCE(a.id, -1) 这类表达式时，往往很难按普通等值条件使用，查询性能可能明显下降。
再往下还有类型问题。比如：
COALESCE(a.name, 'N/A')这种通常没问题；但如果写成：
COALESCE(a.id, 'N/A')在 PostgreSQL 里就会直接报错，因为类型不一致。
真正更值得警惕的是语义层面。把 NULL 强行替换成某个值之后，你实际上是在把“缺失”转成“相等”。但业务里两个 NULL 未必代表同一个意思，例如一个是“未填写”，另一个是“不适用”。如果不先确认字段语义，就贸然把它们视为可匹配值，很可能会掩盖原本应该暴露出来的数据质量问题。
怎么选：先看语义，再看兼容性和执行计划
如果只是想快速得到一个结论，可以按下面这个顺序判断：
- 数据库支持时，优先用
IS NOT DISTINCT FROM，语义最清晰，也最接近“正确表达需求” - 需要兼容更多数据库时，使用显式
OR分支，但要接受它在可读性和性能上的代价 COALESCE只适合在你非常确定兜底值安全、类型一致、且性能影响可接受时使用
换句话说，处理 NULL 关联的问题，不能只看“哪种写法能跑通”，更要看它是否符合你的业务含义，以及执行计划是否还能接受。语法正确只是起点，匹配语义和成本控制才是决定方案是否能上线的关键。
