答案是使用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值查询的核心，在于理解NULL并非零、空字符串或任何具体的值，它代表的是“未知”或“不存在”。正是这种不确定性，导致我们在使用常规的等式（
=
）或不等式（
!=
,
<>
）进行比较时，NULL值会表现出一种“隐形”的行为，即任何与NULL进行的比较操作，结果都会是
UNKNOWN
，而不是
TRUE
或
FALSE
。因此，要正确查询或筛选包含NULL值的数据，我们必须使用专门的
IS NULL
或
IS NOT NULL
操作符，或者借助一些函数来转换或替代NULL值，才能让查询逻辑如我们所愿地工作。
解决方案
处理SQL中的NULL值查询，首先要抛开我们日常编程中对“等于”的直观理解。在我看来，NULL的这种特殊性是SQL设计哲学的一个体现，它迫使我们更严谨地思考数据的完整性和未知状态。
最直接也是最基础的方法，就是使用
IS NULL
和
IS NOT NULL
。例如，如果你想找出所有
字段为空的客户，你不能写
WHERE email = NULL
，这几乎总是会返回空结果集，因为
NULL = NULL
的结果也是
UNKNOWN
。正确的做法是
WHERE email IS NULL
。反之，要查找所有
不为空的客户，则是
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
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
是
0
（明确无折扣）的产品，那么
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
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
匹配。
举个例子，假设我们有两个表：
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
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
时靠前。
为了消除这种不确定性，并确保跨数据库系统的一致性，SQL标准提供了
NULLS FIRST
和
NULLS LAST
子句。 例如，
ORDER BY column_name ASC NULLS FIRST
会将
NULL
值排在最前面，即使是升序。
ORDER BY column_name DESC NULLS LAST
会将
NULL
值排在最后面，即使是降序。
我个人在编写需要精确排序的查询时，总是倾向于明确指定
NULLS FIRST
或
NULLS LAST
。这不仅仅是为了兼容性，更是为了让查询的意图清晰可见，避免因为
NULL
值的默认排序行为而产生意外的结果。毕竟，数据分析的价值在于其准确性和可信度，而
NULL
值的处理正是构建这种可信度的重要一环。
mysql oracle ai 数据清洗 区别 聚合函数 sql mysql NULL count select 字符串 oracle postgresql 数据库 数据分析