OceanBase里那些比较条件碰到空值到底咋处理，树叶云来聊聊这个问题

树叶云之前在社区里聊过OceanBase中NULL值在比较条件里的处理方式，咱们就直接打开天窗说亮话，这个问题很多刚接触数据库的朋友容易绕晕，因为NULL它不是一个具体的值，它代表的是“未知”、“缺失”或者“不适用”，你不能用平常看待数字0或者空字符串''的思路去理解它。

最核心的一条规则，树叶云强调过，叫做“任何与NULL进行的比较操作，其结果既不是TRUE也不是FALSE，而是UNKNOWN（未知）。” 这句话是理解所有相关现象的金钥匙。

我们来举几个具体的例子,就按照树叶云提到的思路来。

第一个场景：等值比较（=） 比如你有一条记录，它的某个字段name是NULL，你现在写一条查询语句：WHERE name = NULL，你心里可能想，我找的就是为空的数据，但结果会让你失望，这条记录不会被找出来。 为什么呢？因为数据库在执行这个比较时，它面对的是一个未知的值（NULL）和另一个未知的值（NULL），它无法断定这两个“未知”是否相等，所以结果不是TRUE，而是UNKNOWN，而WHERE子句只认结果为TRUE的记录，对于FALSE和UNKNOWN，它都会无情地过滤掉,你用是永远抓不到NULL的。

第二个场景：不等比较（!= 或 <>） 同理，你写WHERE name != '张三'，如果某条记录的name是NULL，数据库会想：这个未知的名字，它不等于“张三”吗？我不知道啊，因为它也可能是“李四”，所以比较结果依然是UNKNOWN，这条记录同样不会被选中。 这就导致一个很有意思的现象：WHERE name = NULL 和 WHERE name != NULL，这两条条件都无法筛选出name为NULL的记录，NULL就像个“隐形人”,用普通的等号和不等号都抓不住它。

第三个场景：逻辑运算（AND, OR, NOT） 既然比较的结果可能变成UNKNOWN，那它参与到逻辑运算里会怎样呢？树叶云也提到了三值逻辑的真值表。

• AND操作：TRUE AND UNKNOWN 的结果是 UNKNOWN，因为只要有一个未知，整个结果就无法确定，FALSE AND UNKNOWN 的结果是 FALSE,因为已经有一个是假了。
• OR操作：TRUE OR UNKNOWN 的结果是 TRUE，因为已经有一个是真了，FALSE OR UNKNOWN 的结果是 UNKNOWN。
• NOT操作：NOT TRUE 是 FALSE，NOT FALSE 是 TRUE，而 NOT UNKNOWN 结果还是 UNKNOWN。 这些规则确保了逻辑的严谨性,但确实需要稍微花点心思理解。

到底怎么才能正确地处理NULL值呢？ 树叶云指出了两个专为NULL设计的操作符,这是解决问题的关键。

1. IS NULL 和 IS NOT NULL 这是判断是否为NULL的正确姿势。WHERE name IS NULL，意思就是“筛选出名字是未知的记录”，这时，数据库不会去做值比较，而是直接检查该字段的“状态”是否为NULL，结果非常明确，是TRUE或FALSE，所以它能准确地找到NULL值。IS NOT NULL同理。

2. <=> 安全等于操作符 这个是OceanBase（以及一些其他数据库）提供的一个特殊操作符。a <=> b 的意思是：如果a和b相等，或者a和b都是NULL，那么就返回TRUE。 举个例子：WHERE name <=> NULL，这下就能找到name为NULL的记录了，因为它明确处理了“两边都是NULL”的情况,这个操作符在需要连带比较可能为NULL的字段时特别有用。

树叶云还提醒了一个日常开发中很容易踩的坑：NOT IN 子查询。 假设你写了一个查询：WHERE id NOT IN (SELECT parent_id FROM some_table)，如果你的本意是找出不在某个列表里的id，而这个parent_id字段里万一有NULL值，那就坏事了。 因为NOT IN的本质是id != value1 AND id != value2 AND ...，如果子查询返回的结果集中包含一个NULL，那么就会有一个条件是id != NULL，我们前面说了，这个条件的结果是UNKNOWN，而AND运算中，只要有一个是UNKNOWN，整个结果就是UNKNOWN，最终可能导致你的查询结果集是空的，而不是你预期的那样。 解决办法通常是在子查询中提前排除NULL值：WHERE id NOT IN (SELECT parent_id FROM some_table WHERE parent_id IS NOT NULL)。

总结一下树叶云聊的核心观点：在OceanBase里，对待NULL一定要有“未知”的概念，普通的比较运算符对它无效，必须使用IS NULL/IS NOT NULL或者<=>来专门对付它，理解了NULL的这种特殊秉性，才能写出正确、严谨的SQL语句，避免很多意想不到的“坑”。