SQL如何检查字段是否为空？IS NULL与IS NOT NULL判断
在数据库查询中，判断字段是否为空，可以说是每个开发者都会遇到的基本操作。但就是这个看似简单的操作，却藏着不少容易踩坑的细节。今天，我们就来彻底理清其中的门道。
IS NULL 和 IS NOT NULL 是唯一标准写法
开门见山，在SQL里检查一个字段是否为空，必须使用 IS NULL 或 IS NOT NULL。千万别用等号，比如 = NULL 或者 != NULL —— 这么写，查询结果永远会让你失望，因为它返回的是 UNKNOWN，最终被当作 false 处理，什么数据都查不到。
为什么会这样？根源在于SQL独特的“三值逻辑”（true/false/unknown）。这里的 NULL 代表的是“未知值”，它既不是空字符串，也不是数字零，而是一个特殊标记，压根不参与常规的比较运算。
WHERE col = NULL→ 永远匹配不上，哪怕这列全是 NULL 值。WHERE col IS NULL→ 这才是正确找出 NULL 值的姿势。WHERE col IS NOT NULL→ 能排除 NULL，但请注意：它不会过滤掉空字符串''或 0。
空字符串、零、空白字符 ≠ NULL，要分开处理
一个常见的误解是，以为用 IS NULL 就能一网打尽所有“看起来空”的数据。现实可没这么简单。下面这些值，在数据库眼里，都不是 NULL：
- 空字符串：
'' - 全是空格的字符串：
' ' - 数字零：
0（针对数值型字段） - 特殊日期如 '0000-00-00'（在MySQL的某些兼容模式下）
所以，如果你的业务需求是要把“缺失值”和“未填写”（空字符串）都找出来，那就得显式地补充条件：
WHERE col IS NULL OR col = '' OR TRIM(col) = ''
这里有个技术细节：TRIM() 函数在不同数据库中的支持度略有差异。PostgreSQL和MySQL原生支持，SQL Server通常用 RTRIM(LTRIM()) 组合，而Oracle也支持 TRIM()。另外，对于数值型字段，要不要加上 OR col = 0 可得三思，因为0很可能是一个完全合法的业务数值。
在 WHERE、JOIN、GROUP BY 中 NULL 的行为差异
NULL 的“古怪”脾气不仅影响简单的条件过滤，还会波及到表连接和分组聚合：
- JOIN 操作：使用
JOIN ON a.id = b.id时，如果连接键的任一方是 NULL，这一行记录就不会被关联上。原因还是那个：NULL = NULL的结果是 false。如果想实现“NULL 与 NULL 也算匹配”的逻辑，就得把条件改写为：ON (a.id = b.id) OR (a.id IS NULL AND b.id IS NULL)。 - GROUP BY：进行分组时，所有的 NULL 值会被归到同一组里。这一点是SQL标准行为，绝大多数数据库都遵循。
- ORDER BY：排序时，NULL 值的位置因数据库而异，有的默认排在最前（如PostgreSQL），有的默认放在最后（如MySQL）。如果想精确控制，可以用
ORDER BY col IS NULL, col这样的写法来显式指定。
用 COALESCE 或 CASE 预处理 NULL 更可控
直接使用 IS NULL 判断适合做条件过滤。但如果想在查询结果里，用一个统一的占位符（比如‘未知’）来替换掉 NULL，更优雅的做法是使用 COALESCE 函数：
SELECT COALESCE(name, '未知') AS name FROM users;
它比写一长串 CASE WHEN name IS NULL THEN '未知' ELSE name END 要简洁得多。不过得留个心眼：COALESCE 返回的是第一个非 NULL 表达式的数据类型，如果前后类型不一致，在某些数据库里可能会触发隐式转换，甚至报错（比如尝试把整数列和字符串 ‘N/A’ 合并时）。
遇到更复杂的逻辑，比如需要把 NULL、空字符串、有效值分开统计时，就别指望一个 IS NULL 能包打天下了。老老实实用 CASE 表达式配合多重判断，才是稳妥的选择。
说到底，在动手写SQL之前，最关键的一步是厘清业务上所谓的“空”到底指什么：是数据缺失（NULL）？是用户未填写（空字符串）？还是某个代表无效的默认值（比如0或‘1970-01-01’）？定义清楚了，再选择合适的判断组合。漏掉任何一种情况，都可能为后续的数据分析埋下偏差的种子。
