在数据库开发中，关联查询时两个字段明明都是空值，却怎么也匹配不到一起，这是不少人踩过的坑。比如订单表的备注字段和退货表的备注字段都是NULL，用t1.remark = t2.remark去关联，结果一条数据都查不出来。原因其实很简单：在SQL的三值逻辑体系里，NULL表示未知，而未知的值不能参与普通的相等比较，NULL = NULL的运算结果既不是TRUE也不是FALSE，而是UNKNOWN，WHERE条件里UNKNOWN会被当作不成立处理，于是关联就悄悄失败了。
为什么NULL不能直接用等号比较
要理解这个问题，得先弄清楚SQL的三值逻辑。普通编程语言里布尔运算只有TRUE和FALSE两种结果，而SQL额外引入了第三个值UNKNOWN，专门用来处理数据缺失或未知的场景。当比较运算的任意一侧是NULL时，比如NULL = 1、NULL = NULL甚至NULL != NULL，结果统统是UNKNOWN。
在WHERE子句和JOIN的ON条件中，只有结果为TRUE的行才会被保留，UNKNOWN和FALSE一样会被过滤掉。这就解释了为什么两个NULL字段用等号关联匹配不上，不是数据有问题，是比较运算本身的语义就决定了这个结果。
看一个简单的验证例子：
SELECT CASE WHEN NULL = NULL THEN '相等' ELSE '不相等' END AS result1,
CASE WHEN NULL IS NULL THEN '是NULL' ELSE '不是NULL' END AS result2;
-- 输出：result1 = 不相等，result2 = 是NULL第一个CASE因为NULL = NULL返回UNKNOWN，走了ELSE分支；第二个用的是IS NULL判断，这是SQL里专门用来检测NULL的语法，结果正常。可见处理NULL必须用专门的谓词，普通运算符在这里帮不上忙。
IS NOT DISTINCT FROM语法的原理与用法
SQL标准提供了IS NOT DISTINCT FROM这个运算符，可以理解为把NULL当作一个普通值来比较。它的语义是：两个操作数要么值相等，要么都是NULL，都算匹配成功。与之配套的还有IS DISTINCT FROM，表示两个值不相等或者其中一个是NULL。这两个运算符把三值逻辑压缩成了确定的TRUE或FALSE，非常适合用在关联和过滤场景。
用标准语法改写前面失败的关联：
SELECT o.order_id, o.remark, r.refund_id FROM orders o JOIN refunds r ON o.remark IS NOT DISTINCT FROM r.remark AND o.order_id = r.order_id;
这样写之后，两边都是NULL的记录也能正常关联上，且非NULL值依然按普通的相等规则匹配。需要留意的是各数据库的支持情况有差异：PostgreSQL从15版本开始原生支持，SQLite支持，而MySQL和SQL Server至今没有实现这个语法，需要用等价写法替代。
MySQL中的等价写法是利用空值合并函数，把NULL替换成一个业务中绝对不会出现的哨兵值再比较：
SELECT o.order_id, o.remark, r.refund_id FROM orders o JOIN refunds r ON COALESCE(o.remark, '__NULL__') = COALESCE(r.remark, '__NULL__') AND o.order_id = r.order_id;
SQL Server没有COALESCE时也可以用ISNULL函数，思路完全一样：
ON ISNULL(o.remark, '__NULL__') = ISNULL(r.remark, '__NULL__')
还有一种通用的逻辑展开写法，任何数据库都能跑：
ON (o.remark = r.remark OR (o.remark IS NULL AND r.remark IS NULL))
这种写法不依赖哨兵值，语义最清晰，但在数据量大时优化器往往难以利用索引，性能上要多加注意。
关联场景下的常见陷阱与性能优化
实际项目里，NULL引发的关联问题通常不止匹配失败一种。LEFT JOIN时右表字段为NULL是正常现象，但如果我们用WHERE r.id IS NULL来判断没有匹配上的记录，这个写法是成立的；可如果顺手写成WHERE r.id != 123，那些r.id为NULL的行同样会被过滤掉，导致统计结果偏少。这类隐蔽的数据丢失比直接报错更难排查。
性能方面要重点关注索引的可用性。对JOIN列套一层函数（比如COALESCE或ISNULL）之后，普通索引通常就失效了，因为索引存的是原始值，函数计算后的结果索引无法直接定位。PostgreSQL里可以建一个表达式索引来补救：
CREATE INDEX idx_orders_remark ON orders (COALESCE(remark, '__NULL__'));
MySQL 8.0以上则支持函数索引，写法类似：
CREATE INDEX idx_orders_remark ON orders ((COALESCE(remark, '__NULL__')));
另一个更彻底的思路是在表设计阶段就减少可空关联列的出现。如果业务允许，给字段设置默认值，比如空字符串代替NULL，关联逻辑就能回归普通的等值比较，索引也能正常使用。很多团队在数仓建设中明确约定关联键不允许NULL，也是出于同样的考虑。
最后总结一下选择建议：如果数据库支持IS NOT DISTINCT FROM，直接用它，语义最标准；不支持的话，优先用IS NULL配对的逻辑展开写法保证正确性，确认性能有瓶颈再考虑哨兵值加函数索引的方案。无论哪种方案，写完关联查询后建议用几条包含NULL的测试数据验证一下匹配结果，避免线上出现数据悄悄丢失的情况。
SQL NULL匹配IS NOT DISTINCT FROM关联查询修改时间：2026-09-06 09:12:28