SQL 如何处理 NULL 值的查询问题？-SQL-PHP中文网

答案是使用IS NULL、IS NOT NULL操作符及COALESCE等函数处理NULL值。因为NULL代表未知，与任何值比较结果均为UNKNOWN，故WHERE子句中需用IS NULL/IS NOT NULL判断；JOIN时NULL无法匹配，可用LEFT JOIN结合COALESCE处理；聚合函数自动忽略NULL，COUNT(*)包含NULL行；排序时NULL位置因数据库而异，应使用NULLS FIRST/LAST明确指定。

sql 如何处理 null 值的查询问题？

SQL处理NULL值查询的核心，在于理解NULL并非零、空字符串或任何具体的值，它代表的是“未知”或“不存在”。正是这种不确定性，导致我们在使用常规的等式（

登录后复制

）或不等式（

!=

登录后复制

<>

登录后复制

）进行比较时，NULL值会表现出一种“隐形”的行为，即任何与NULL进行的比较操作，结果都会是

UNKNOWN

登录后复制

，而不是

TRUE

登录后复制

或

FALSE

登录后复制

。因此，要正确查询或筛选包含NULL值的数据，我们必须使用专门的

IS NULL

登录后复制

或

IS NOT NULL

登录后复制

操作符，或者借助一些函数来转换或替代NULL值，才能让查询逻辑如我们所愿地工作。

解决方案

处理SQL中的NULL值查询，首先要抛开我们日常编程中对“等于”的直观理解。在我看来，NULL的这种特殊性是SQL设计哲学的一个体现，它迫使我们更严谨地思考数据的完整性和未知状态。

最直接也是最基础的方法，就是使用

IS NULL

登录后复制

和

IS NOT NULL

登录后复制

。例如，如果你想找出所有

email

登录后复制

字段为空的客户，你不能写

WHERE email = NULL

登录后复制

，这几乎总是会返回空结果集，因为

NULL = NULL

登录后复制

的结果也是

UNKNOWN

登录后复制

。正确的做法是

WHERE email IS NULL

登录后复制

。反之，要查找所有

email

登录后复制

不为空的客户，则是

WHERE email IS NOT NULL

登录后复制

。这种明确的指定，避免了与

UNKNOWN

登录后复制

结果的纠缠。

再进一步，当我们需要在查询结果中把NULL值替换成一个有意义的默认值时，

COALESCE

登录后复制

函数就显得非常有用。

COALESCE(expr1, expr2, ..., exprN)

登录后复制

会返回其参数列表中第一个非NULL的表达式。这在报表生成或数据展示时尤为重要。比如，一个用户可能没有填写

phone_number

登录后复制

，我们希望显示为“未提供”，那么

SELECT COALESCE(phone_number, '未提供') AS contact_info FROM users;

登录后复制

就能实现。类似的函数还有

IFNULL

登录后复制

（MySQL）、

NVL

登录后复制

（Oracle）等，它们通常只接受两个参数，但核心思想一致。

在进行数据聚合时，NULL值的处理也值得深思。大多数聚合函数（如

SUM()

登录后复制

AVG()

登录后复制

COUNT()

登录后复制

MAX()

登录后复制

MIN()

登录后复制

）在计算时会默认忽略NULL值。这通常是符合预期的，因为我们通常不希望“未知”的值影响到平均值或总和。但如果你确实想把NULL值计入，例如在计算平均值时把NULL视为0，那么你需要在聚合函数内部使用

COALESCE

登录后复制

：

AVG(COALESCE(score, 0))

登录后复制

。

COUNT(*)

登录后复制

会计算所有行，包括含有NULL值的行，而

COUNT(column_name)

登录后复制

则只计算

column_name

登录后复制

非NULL的行。

另外，

NULLIF(expr1, expr2)

登录后复制

函数也很有趣，它在

expr1

登录后复制

等于

expr2

登录后复制

时返回NULL，否则返回

expr1

登录后复制

。这在处理一些特殊数据清洗场景时，可以将某些特定值（例如，用0表示“无数据”但又不想它参与计算）转换为NULL，从而利用聚合函数忽略NULL的特性。

理解这些基本操作和函数，是有效处理SQL中NULL值的关键。它不仅仅是语法上的要求，更是一种数据思维上的转变。

NULL

登录后复制

值在

WHERE

登录后复制

子句中的“隐形”行为解析

当我们谈论

WHERE

登录后复制

子句中的

NULL

登录后复制

值时，我总觉得它像一个“隐形人”，你不能直接指着它说“你就是我想要找的那个”，因为一旦你尝试用

登录后复制

或

!=

登录后复制

去指认它，它就会变得“不可比较”。这种行为，说实话，一开始确实让人摸不着头脑，甚至会犯错。

核心在于SQL的三值逻辑（

TRUE

登录后复制

FALSE

登录后复制

UNKNOWN

登录后复制

）。任何与

NULL

登录后复制

的比较，无论是

NULL = 1

登录后复制

，

NULL != 1

登录后复制

，甚至

NULL = NULL

登录后复制

，其结果都不是

TRUE

登录后复制

或

FALSE

登录后复制

，而是

UNKNOWN

登录后复制

。

WHERE

登录后复制

子句只返回那些评估结果为

TRUE

登录后复制

的行。这意味着，如果你的条件最终评估为

UNKNOWN

登录后复制

，那么对应的行就不会被包含在结果集中。

举个例子，假设你有一个

products

登录后复制

表，其中

discount_percentage

登录后复制

字段可能为

NULL

登录后复制

。如果你写：

SELECT * FROM products WHERE discount_percentage = 0;

登录后复制

，这会返回所有折扣百分比明确为0的产品。如果你写：

SELECT * FROM products WHERE discount_percentage != 0;

登录后复制

，这会返回所有折扣百分比明确不为0（例如10%, 20%）的产品。但如果你想找出所有没有折扣的产品，包括那些

discount_percentage

登录后复制

是

NULL

登录后复制

（未知是否有折扣）和

discount_percentage

登录后复制

是

登录后复制

（明确无折扣）的产品，那么

discount_percentage = 0 OR discount_percentage IS NULL

登录后复制

才是正确的做法。

这种“隐形”行为也延伸到了

NOT IN

登录后复制

操作符。

NOT IN

登录后复制

的内部逻辑实际上是一系列

AND

登录后复制

连接的不等式比较。如果

NOT IN

登录后复制

的列表中包含

NULL

登录后复制

，那么整个表达式的结果就可能变成

UNKNOWN

登录后复制

，导致查询返回空集或不完整的结果。比如，

SELECT * FROM users WHERE user_id NOT IN (SELECT blocked_user_id FROM blocked_users);

登录后复制

如果

blocked_users

登录后复制

表中

blocked_user_id

登录后复制

字段有

NULL

登录后复制

值，那么这个查询可能会出现非预期的结果。为了安全起见，通常需要确保

NOT IN

登录后复制

子查询的结果集中不包含

NULL

登录后复制

值，例如通过

WHERE blocked_user_id IS NOT NULL

登录后复制

来过滤。

理解这种

UNKNOWN

登录后复制

的传递性，是避免

WHERE

登录后复制

子句中

NULL

登录后复制

值陷阱的关键。它要求我们对数据状态有更清晰的认识，并用

IS NULL

登录后复制

、

IS NOT NULL

登录后复制

或适当的函数来明确表达我们的意图。

如何巧妙地在

JOIN

登录后复制

操作中驾驭

NULL

登录后复制

值

在

JOIN

登录后复制

操作中处理

NULL

登录后复制

值，这可真是个让人头疼又充满挑战的场景。我个人觉得，这里面的“坑”比

WHERE

登录后复制

子句还要隐蔽一些，因为它常常涉及到两个表之间的数据关联逻辑。

首先要明确的是，

JOIN

登录后复制

条件中的

ON

登录后复制

子句也遵循SQL的三值逻辑。这意味着，如果你的

JOIN

登录后复制

条件是

table1.column_a = table2.column_b

登录后复制

，并且

column_a

登录后复制

或

column_b

登录后复制

（或两者）为

NULL

登录后复制

，那么这个比较的结果就是

UNKNOWN

登录后复制

。对于

INNER JOIN

登录后复制

，只有当

ON

登录后复制

条件评估为

TRUE

登录后复制

时，行才会被匹配。因此，含有

NULL

登录后复制

值的行永远不会通过常规的等式

JOIN

登录后复制

条件被

INNER JOIN

登录后复制

匹配。

蓝心千询

蓝心千询是vivo推出的一个多功能AI智能助手

查看详情

举个例子，假设我们有两个表：

employees

登录后复制

（

employee_id

登录后复制

manager_id

登录后复制

）和

managers

登录后复制

（

manager_id

登录后复制

manager_name

登录后复制

）。如果某个员工的

manager_id

登录后复制

是

NULL

登录后复制

（表示他没有直接经理或者他是最高层），那么

INNER JOIN employees ON employees.manager_id = managers.manager_id

登录后复制

将不会把这个员工匹配到任何经理，这是符合预期的。

但如果我们的业务逻辑要求将那些

manager_id

登录后复制

为

NULL

登录后复制

的员工也包含进来，并且我们想为他们显示一个特定的状态（比如“顶层员工”），这时候

LEFT JOIN

登录后复制

就派上用场了。

LEFT JOIN

登录后复制

会返回左表中的所有行，即使右表中没有匹配的行。对于那些没有匹配的行，右表对应的列将显示为

NULL

登录后复制

。然后，我们就可以利用

COALESCE

登录后复制

等函数在

SELECT

登录后复制

列表中处理这些

NULL

登录后复制

值。

SELECT e.employee_id, e.manager_id, COALESCE(m.manager_name, '顶层员工') AS manager_name_display FROM employees e LEFT JOIN managers m ON e.manager_id = m.manager_id;

登录后复制

这里有个更复杂但很有用的技巧：如果你想在

JOIN

登录后复制

条件中将

NULL

登录后复制

值也视为“相等”来匹配，例如，两个字段都为

NULL

登录后复制

时，你也认为它们是匹配的。常规的

ON table1.col = table2.col

登录后复制

是做不到的。这时候，你可以使用

IS NOT DISTINCT FROM

登录后复制

（SQL标准，但并非所有数据库都支持，例如MySQL就不支持）或者更通用的

OR

登录后复制

条件：

SELECT * FROM table1 t1 JOIN table2 t2 ON (t1.col = t2.col OR (t1.col IS NULL AND t2.col IS NULL));

登录后复制

这种写法虽然稍微冗长，但它明确地处理了

NULL

登录后复制

与

NULL

登录后复制

的匹配情况，确保了即使在

JOIN

登录后复制

中，

NULL

登录后复制

值也能按照特定的业务逻辑进行关联。在我看来，这正是SQL灵活性和强大之处的体现，它允许我们精确控制数据行为。

NULL

登录后复制

值对 SQL 聚合函数与排序结果的深远影响

NULL

登录后复制

值在聚合函数和排序操作中的行为，是我在数据分析中经常需要注意的地方。它不像简单的筛选那么直接，而是对最终的统计结果和数据呈现顺序有着微妙但深远的影响。

正如前面提到的，大多数聚合函数（

SUM

登录后复制

AVG

登录后复制

MAX

登录后复制

MIN

登录后复制

COUNT(column_name)

登录后复制

）在计算时会默认“跳过”

NULL

登录后复制

值。这通常是符合我们直觉的，因为一个“未知”的数值不应该参与到求和或平均值的计算中去，否则会歪曲真实的数据趋势。比如，如果你有一个

sales

登录后复制

表，

amount

登录后复制

字段可能为

NULL

登录后复制

（表示这笔交易金额未知或未完成），那么

SUM(amount)

登录后复制

只会计算那些有明确金额的交易，这通常是我们想要的。如果想把

NULL

登录后复制

当成0来计算总和，那就得用

SUM(COALESCE(amount, 0))

登录后复制

。这种细微的差别，在做财务或绩效报表时，如果处理不当，可能会导致完全错误的结论。

COUNT(*)

登录后复制

和

COUNT(1)

登录后复制

则是一个例外，它们会计算所有行的数量，包括那些包含

NULL

登录后复制

值的行。而

COUNT(column_name)

登录后复制

则只会计算

column_name

登录后复制

非

NULL

登录后复制

的行。理解这三者的区别，对于准确统计数据至关重要。

再来说说排序 (

ORDER BY

登录后复制

)。

NULL

登录后复制

值在排序时的位置，不同数据库系统有不同的默认行为，这有时候会让人感到困惑。

MySQL: 默认情况下，
```
NULL
```
登录后复制
值在升序 (
```
ASC
```
登录后复制
) 排序时排在最前面，降序 (
```
DESC
```
登录后复制
) 排序时排在最后面。
PostgreSQL: 默认情况下，
```
NULL
```
登录后复制
值在升序 (
```
ASC
```
登录后复制
) 排序时排在最后面，降序 (
```
DESC
```
登录后复制
) 排序时排在最前面。
SQL Server / Oracle: 默认行为与PostgreSQL类似，
```
NULL
```
登录后复制
在
```
ASC
```
登录后复制
时靠后，
```
DESC
```
登录后复制
时靠前。