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值在
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操作中驾驭
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匹配。
Teleporthq
一体化AI网站生成器，能够快速设计和部署静态网站
182
查看详情
举个例子，假设我们有两个表：
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
时靠前。
为了消除这种不确定性，并确保跨数据库系统的一致性，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值的处理正是构建这种可信度的重要一环。
以上就是SQL 如何处理 NULL 值的查询问题？的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql oracle ai 数据清洗 区别 聚合函数 sql mysql NULL count select 字符串 oracle postgresql 数据库 数据分析 大家都在看： 如何建立MySQL远程数据源_MySQL远程连接数据源配置方法 MySQL插入中文数据乱码怎么办_MySQL中文数据插入编码处理 MySQL数据源故障怎么排查_MySQL数据源常见问题解决方法 如何监控MySQL数据源状态_MySQL数据源连接状态监控方法 如何配置MySQL连接池数据源_MySQL连接池数据源设置详解
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。