NULL 用于表示缺失的值或遗漏的未知数据，不是某种具体类型的值。数据表中的 NULL 值表示该值所处的字段为空，值为 NULL 的字段没有值，尤其要明白的是：NULL 值与 0 或者空字符串是不同的。

这种说法大家可能会觉得很奇怪，因为 SQL 里只存在一种 NULL 。然而在讨论 NULL 时，我们一般都会将它分成两种类型来思考：“未知”（unknown）和“不适用”（not applicable,inapplicable）。

以“不知道戴墨镜的人眼睛是什么颜色”这种情况为例，这个人的眼睛肯定是有颜色的，但是如果他不摘掉眼镜，别人就不知道他的眼睛是什么颜色。这就叫作未知。

而“不知道冰箱的眼睛是什么颜色”则属于“不适用”。因为冰箱根本就没有眼睛，所以“眼睛的颜色”这一属性并不适用于冰箱。“冰箱的眼睛的颜色”这种说法和“圆的体积”“男性的分娩次数”一样，都是没有意义的。

平时，我们习惯了说“不知道”，但是“不知道”也分很多种。“不适用”这种情况下的 NULL ，在语义上更接近于“无意义”，而不是“不确定”。

这里总结一下：“未知”指的是“虽然现在不知道，但加上某些条件后就可以知道”；而“不适用”指的是“无论怎么努力都无法知道”。

关系模型的发明者 E.F. Codd 最先给出了这种分类。下图是他对“丢失的信息”的分类。

为什么必须写成“IS NULL”，而不是“＝ NULL”？我相信不少人有这样的困惑吧，尤其是相信刚学 SQL 的小伙伴。我们来看个具体的案例，假设我们有如下表以及数据：

我们要查询备注为 NULL 的记录（为 NULL 这种叫法本身是不对的，只是我们日常中已经叫习惯了，具体往下看），怎么查，很多新手会写出这样的 SQL：

执行时不报错，但是查不出我们想要的结果， 这是为什么 ？这个问题我们先放着，我们往下看。

这个三值逻辑不是三目运算，指的是三个逻辑值，有人可能有疑问了，逻辑值不是只有真(true)和假(false)吗，哪来的第三个？

说这话时我们需要注意所处的环境，在主流的编程语言中（C、JAVA、Python、JS等）中，逻辑值确实只有 2 个，但在 SQL 中却存在第三个逻辑值：unknown。这有点类似于我们平时所说的：对、错、不知道。

逻辑值 unknown 和作为 NULL 的一种的 UNKNOWN （未知）是不同的东西。前者是明确的布尔型的逻辑值，后者既不是值也不是变量。

为了便于区分，前者采用小写字母 unknown ，后者用大写字母 UNKNOWN 来表示。为了让大家理解两者的不同，我们来看一个 x=x 这样的简单等式。x 是逻辑值 unknown 时，x=x 被判断为 true ，而 x 是 UNKNOWN 时被判断为 unknown 。

NOT：

AND：

OR：

图中蓝色部分是三值逻辑中独有的运算，这在二值逻辑中是没有的。其余的 SQL 谓词全部都能由这三个逻辑运算组合而来。从这个意义上讲，这个几个逻辑表可以说是 SQL 的母体（matrix）。

NOT 的话，因为逻辑值表比较简单，所以很好记；但是对于 AND 和 OR，因为组合出来的逻辑值较多，所以全部记住非常困难。为了便于记忆，请注意这三个逻辑值之间有下面这样的优先级顺序：

优先级高的逻辑值会决定计算结果。例如 true AND unknown ，因为 unknown 的优先级更高，所以结果是 unknown 。而 true OR unknown 的话，因为 true 优先级更高，所以结果是 true 。

记住这个顺序后就能更方便地进行三值逻辑运算了。特别需要记住的是，当 AND 运算中包含 unknown 时，结果肯定不会是 true （反之，如果AND 运算结果为 true ，则参与运算的双方必须都为 true ）。

我们再回到问题：为什么必须写成“IS NULL”，而不是“＝ NULL”？

对 NULL 使用比较谓词后得到的结果总是 unknown 。而查询结果只会包含 WHERE 子句里的判断结果为 true 的行，不会包含判断结果为 false 和 unknown 的行。不只是等号，对 NULL 使用其他比较谓词，结果也都是一样的。

所以无论 remark 是不是 NULL ，比较结果都是 unknown ，那么永远没有结果返回。以下的式子都会被判为 unknown：

那么，为什么对 NULL 使用比较谓词后得到的结果永远不可能为真呢？

这是因为，NULL 既不是值也不是变量。NULL 只是一个表示“没有值”的标记，而比较谓词只适用于值。

因此，对并非值的 NULL 使用比较谓词本来就是没有意义的。“列的值为 “NULL ”、“NULL 值” 这样的说法本身就是错误的。因为 NULL不是值，所以不在定义域（domain）中。

相反，如果有人认为 NULL 是值，那么我们可以倒过来想一下：它是什么类型的值？关系数据库中存在的值必然属于某种类型，比如字符型或数值型等。所以，假如 NULL 是值，那么它就必须属于某种类型。

NULL 容易被认为是值的原因有两个。

第一个是高级编程语言里面，NULL 被定义为了一个常量（很多语言将其定义为了整数0），这导致了我们的混淆。但是，SQL 里的 NULL 和其他编程语言里的 NULL 是完全不同的东西。

第二个原因是，IS NULL 这样的谓词是由两个单词构成的，所以我们容易把 IS 当作谓词，而把 NULL 当作值。特别是 SQL 里还有 IS TRUE 、IS FALSE 这样的谓词，我们由此类推，从而这样认为也不是没有道理。但是正如讲解标准 SQL 的书里提醒人们注意的那样，我们应该把 IS NULL 看作是一个谓词。因此，写成 IS_NULL 这样也许更合适。

排中律不成立。排中律指同一个思维过程中，两个相互矛盾的思想不能同假，必有一真，即“要么A要么非A”。

假设我们有学生表：t_student：

表中数据 yzb 的 age 是 NULL，也就是说 yzb 的年龄未知。在现实世界里，yzb 是 20 岁，或者不是 20 岁，二者必居其一，这毫无疑问是一个真命题。那么在 SQL 的世界里了，排中律还适用吗? 我们来看一个 SQL ：

咋一看，这不就是查询表中全部记录吗？我们来看下实际结果：

yzb 没查出来，这是为什么？我们来分析下，yzb 的 age 是 NULL，那么这条记录的判断步骤如下：

SQL 语句的查询结果里只有判断结果为 true 的行。要想让 yzb 出现在结果里，需要添加下面这样的 “第 3 个条件”：

CASE 表达式和 NULL。简单 CASE 表达式如下：

这个 CASE 表达式一定不会返回 ×。这是因为，第二个 WHEN 子句是 col_1 = NULL 的缩写形式。正如我们所知，这个式子的逻辑值永远是 unknown ，而且 CASE 表达式的判断方法与 WHERE 子句一样，只认可逻辑值为 true 的条件。正确的写法是像下面这样使用搜索 CASE 表达式：

我们在对 SQL 语句进行性能优化时，经常用到的一个技巧是将 IN 改写成 EXISTS ，这是等价改写，并没有什么问题。但是，将 NOT IN 改写成 NOT EXISTS 时，结果未必一样。

我们来看个例子，我们有如下两张表：t_student_A 和 t_student_B，分别表示 A 班学生与 B 班学生。

需求：查询与 A  班住在深圳的学生年龄不同的 B 班学生，也就说查询出 ：马化腾 和 李彦宏，这个 SQL 该如何写，像这样？

我们来看下执行结果：

我们发现结果是空，查询不到任何数据，这是为什么 ？这里 NULL 又开始作怪了，我们一步一步来看看究竟发生了什么。

可以看出，在进行了一系列的转换后，没有一条记录在 WHERE 子句里被判断为 true 。也就是说，如果 NOT IN 子查询中用到的表里被选择的列中存在 NULL ，则 SQL 语句整体的查询结果永远是空。这是很可怕的现象！

为了得到正确的结果，我们需要使用 EXISTS 谓词。

执行结果如下：

同样地，我们再来一步一步地看看这段 SQL 是如何处理年龄为 NULL 的行的：

也就是说，yzb 被作为 “与任何人的年龄都不同的人” 来处理了。EXISTS 只会返回 true 或者false，永远不会返回 unknown。因此就有了 IN 和 EXISTS 可以互相替换使用，而 NOT IN和 NOT EXISTS 却不可以互相替换的混乱现象。

还有一些其他的陷阱，比如：限定谓词和 NULL、限定谓词和极值函数不是等价的、聚合函数和 NULL 等等。

1、NULL 用于表示缺失的值或遗漏的未知数据，不是某种具体类型的值，不能对其使用谓词。

2、对 NULL 使用谓词后的结果是 unknown，unknown 参与到逻辑运算时，SQL 的运行会和预想的不一样。

3、 IS NULL 整个是一个谓词，而不是：IS 是谓词，NULL 是值；类似的还有 IS TRUE、IS FALSE。

4、要想解决 NULL 带来的各种问题，最佳方法应该是往表里添加 NOT NULL 约束来尽力排除 NULL。

我的项目中有个硬性规定：所有字段必须是 NOT NULL，建表的时候就加上此约束。