SQL Server NULL值全解析：三值逻辑与避坑指南

前几天有个新同事调订单金额汇总，跑出来的 SUM 是 NULL，页面直接空白。找半天没发现问题，最后发现 GROUP BY 的分组字段里混了 NULL；紧接着又有个同事拼客户地址，省市区三段用加号拼完，某个字段为空，整条地址不见了。这类问题我被反复问过太多次，所以这一篇笔记，想单独把 SQL Server 里的 NULL 值拎出来，从概念、存储、三值逻辑、函数行为，一直到索引和应用层交互，一次说透。

这篇内容对谁有用？刚学 T-SQL 的开发者、天天跟报表统计打交道的数据分析师、以及被各种“诡异”查询结果折腾过但又没时间深挖的 DBA。看完之后，你至少能稳稳避开最常见的 NULL 陷阱，在排查问题时第一时间把怀疑目光放到 NULL 头上。

1. 从一次报表事故说起：NULL到底是个什么“值”

1.1 把NULL理解成“未赋值”而不是“空”

很多初学者会把 NULL 和 0、空字符串混为一谈，这是第一个大坑。0 是一个确定的数字，空字符串是一个长度为 0 的确定字符串，而 NULL 在 SQL 里的语义是“未知”或者“没有值”。举个生活中的例子：客户表里手机号字段是 NULL，表示系统根本不知道这个客户的手机号，而不是他手机号是空字符串，更不是手机号号码是 0。

这个区别在统计场景下特别致命。比如算全班平均成绩，缺考的人成绩列是 NULL，那 AVG 应该只算参加考试的人；如果你把 NULL 转成 0 再算，平均分一下子就拉低了，而且这个结果在业务上是错的。反过来，如果领导问“这个月订单金额是多少”，如果恰好整列数据都是 NULL，SUM 返回 NULL，页面上显示一片空白，而不是 0，这也是 NULL 带来的经典问题。

注意：NULL 不是“空”的意思，而是“不知道”。这个语义差别会直接影响 SQL 的运算结果，尤其在做统计报表时，差别就是“正确结果”和“离奇结果”的区别。

1.2 NULL在SQL Server里是怎么存的

从存储层面看，NULL 也很特殊。SQL Server 的一行数据里，会有一小块区域叫 NULL 位图，专门记录这一行里哪些列是 NULL。如果某个字段值是 NULL，行数据区里不会写入这个字段的实际内容，只在位图上把对应 bit 置为 1；如果字段有值，bit 置为 0，并把真实值写进数据区。

所以“NULL 不占空间”这个说法，严格来说要加个限定：NULL 值本身不占普通数据区的空间，但位图会占一点点空间。如果你设计一张表，很多列允许 NULL，而且实际存了大量 NULL，表占用的空间通常不会因为这些 NULL 变得非常大，这也是很多人敢放开用 NULL 的原因之一。

另外还有个容易忽略的点：NULL 的类型转换。给一个 NULL 赋任何类型都行，因为未知状态没有类型约束，但在参与运算和存储时，它会被当作某个具体类型处理。比如：

sql复制SELECT CAST(NULL AS INT) AS int_null, CAST(NULL AS NVARCHAR(10)) AS str_null;

这种语句在开发规范里很有用，可以明确一个空值的“目标类型”，避免在结果集合并时出现类型冲突。

1.3 NULL = NULL 为什么不成立

这是 T-SQL 开发者最容易翻车的第一道坎：两个 NULL 做比较，结果不是“相等”，也不是“不相等”，而是 UNKNOWN。听起来很反直觉，但如果坚持“NULL 是未知”这个定义，就很好理解：连两个数都不知道是多少，你怎么能断言它们相等？

sql复制SELECT CASE WHEN NULL = NULL THEN '相等' ELSE '不相等' END AS result;

这条查询结果会是“不相等”，因为 NULL = NULL 的结果是 UNKNOWN，CASE 只会对 TRUE 走第一个分支。再比如：

sql复制SELECT * FROM 客户表 WHERE 手机号 = NULL;

这条语句不会返回任何行，因为手机号列的每一个值（哪怕是 NULL）和 NULL 比较，结果都不是 TRUE。

所以判断字段是否为 NULL，永远只能用 IS NULL 或 IS NOT NULL：

sql复制SELECT * FROM 客户表 WHERE 手机号 IS NULL;
SELECT * FROM 客户表 WHERE 手机号 IS NOT NULL;

这里有个很老但是依然存在的开关 SET ANSI_NULLS，默认是 ON，ON 状态下“= NULL”永远返回 UNKNOWN；只有把它改成 OFF，老版本才会允许“= NULL”匹配到 NULL 值。微软官方早就建议不要依赖这个旧行为，我也建议你就当没有这个开关，统一用 IS NULL，这是最稳的写法。

2. 三值逻辑：为什么查询结果会“凭空减少”

2.1 一个比较从两个结果变成了三个结果

普通逻辑里，一个条件判断要么真要么假，二选一。但 SQL 引入了 NULL 之后，多出了第三个状态：UNKNOWN。比如“该员工的部门编号是否等于 10”，如果部门编号是 20，那是 FALSE；如果是 10，那是 TRUE；如果部门编号是 NULL，我们不知道它是不是 10，所以结果是 UNKNOWN。

这个第三态会通过 AND、OR、NOT 传播。几个关键规则值得背下来：

简单记忆方式：AND 只要遇到 FALSE 就是 FALSE，其他都看 UNKNOWN；OR 只要遇到 TRUE 就是 TRUE，其他都看 UNKNOWN；NOT 遇到 UNKNOWN 依然是 UNKNOWN。

2.2 WHERE、CASE WHEN、CHECK约束对UNKNOWN的态度不一样

同一个 UNKNOWN，在不同语法结构里的待遇完全不同，这是最容易迷糊的地方。

WHERE 子句只接受 TRUE 的行，UNKNOWN 会被直接过滤掉。所以你在 WHERE 里写“列 = NULL”，永远过滤掉所有行；哪怕列本身就是 NULL，也不能让它留下。这不是语句写错了，而是三值逻辑在起作用。

CASE WHEN 对 UNKNOWN 的态度是：不进任何 WHEN 分支，如果所有 WHEN 条件都是 UNKNOWN 或 FALSE，就走 ELSE。所以：

sql复制SELECT CASE WHEN NULL = NULL THEN '相等' ELSE '不相等' END;

走的是 ELSE，返回“不相等”。

更隐蔽的是 CHECK 约束。很多人以为 CHECK (age > 0) 能拦住 age 为 NULL 的数据，实际上 SQL Server 的 CHECK 约束只拒绝 FALSE，UNKNOWN 是放行的。也就是说，一条 age 是 NULL 的记录可以顺利插入，因为 age > 0 是 UNKNOWN，而 CHECK 不会因为 UNKNOWN 就报错。这个行为经常让开发者在数据清洗阶段意外接到一堆“漏网”数据。

注意：CHECK 约束拦不住 NULL。如果你想要 age 字段不能为空，必须在列定义上直接写 NOT NULL，而不是指望 CHECK 约束。

2.3 经典陷阱：NOT IN子查询碰上NULL，整个查询直接“消失”

这是三值逻辑在实战中杀伤力最大的场景，先看一个例子：

sql复制CREATE TABLE Employee (
    Id INT PRIMARY KEY,
    Name NVARCHAR(50),
    DepartmentId INT
);

INSERT INTO Employee VALUES (1, N'张三', 10), (2, N'李四', 20), (3, N'王五', NULL);

CREATE TABLE DisabledDepartment (
    Id INT
);

INSERT INTO DisabledDepartment VALUES (10), (NULL);

现在我要查“不在禁用部门里的员工”：

sql复制SELECT * FROM Employee WHERE DepartmentId NOT IN (SELECT Id FROM DisabledDepartment);

直觉上，张三在部门 10，所以不该出现；李四在部门 20，不在禁用列表里，应该出现；王五部门未知，也不该出现。但执行结果往往是一行都没有。为什么？因为子查询返回了 (10, NULL)。SQL 引擎在处理李四时，要判断 20 NOT IN (10, NULL)，等价于 20 <> 10 AND 20 <> NULL。20 <> 10 是 TRUE，20 <> NULL 是 UNKNOWN，TRUE AND UNKNOWN 是 UNKNOWN，所以整行被过滤。于是结果为空集。

解决办法有两个方向。要么把子查询里的 NULL 过滤掉：

sql复制SELECT * FROM Employee
WHERE DepartmentId NOT IN (SELECT Id FROM DisabledDepartment WHERE Id IS NOT NULL);

要么干脆用 NOT EXISTS，这个写法天然规避了 NULL 问题：

sql复制SELECT e.*
FROM Employee e
WHERE NOT EXISTS (SELECT 1 FROM DisabledDepartment d WHERE d.Id = e.DepartmentId);

我个人的习惯是排查 NOT IN 相关问题时第一反应就改成 NOT EXISTS，因为 NOT EXISTS 的语义更接近业务直觉：只要子查询里找不到匹配行，结果就是 TRUE。

3. 聚合、拼接、排序：函数与操作符的NULL行为规则

3.1 聚合函数遇到NULL：忽略还是报错？

聚合函数对 NULL 的态度几乎是统一的：忽略。但“忽略”在不同函数里会产生不同的业务后果，这里有必要逐一说清楚。

这里最容易出错的是 AVG 和 COUNT。拿员工表举例，10 人里 2 人没发绩效工资，绩效字段为 NULL，AVG(绩效) 只算 8 个人，而不是 10 个人。如果你业务上希望把这 2 人当作 0 分参与计算，就要显式转换：

sql复制SELECT AVG(ISNULL(绩效, 0)) AS 平均绩效 FROM 员工表;

COUNT(列) 的坑同样隐蔽：COUNT(*) 数的是行数，COUNT(某列) 数的是非 NULL 值的个数。如果一列有一半是 NULL，两个结果就差了很大一截。排查报表数据对不上时，先要确认统计口径到底应该用哪一个。

再提醒一个细节：SUM 全列为 NULL 时返回 NULL，而不是 0。我见过不少代码没做保护，页面直接显示空白。报表层通常要补一层：

sql复制SELECT ISNULL(SUM(订单金额), 0) AS 订单总额 FROM 订单表;

3.2 字符串拼接NULL：+ 和 CONCAT 结果完全不同

字符串拼接是 NULL 行为的另一大重灾区。在 SQL Server 里，用加号拼接时，只要其中任何一个操作数是 NULL，整个结果就是 NULL：

sql复制SELECT N'北京市' + N'朝阳区' + NULL AS address;

执行结果不是“北京市朝阳区”，而是 NULL。这在拼接客户地址、对账摘要、日志标题时非常常见。解决办法之一是手动把可能为 NULL 的字段转成空串：

sql复制SELECT ISNULL(N'北京市', N'') + ISNULL(N'朝阳区', N'') + ISNULL(NULL, N'') AS address;

如果 SQL Server 版本在 2012 以上，更推荐直接使用 CONCAT 函数，它会把 NULL 自动当成空字符串处理：

sql复制SELECT CONCAT(N'北京市', N'朝阳区', NULL) AS address;

结果就是“北京市朝阳区”，干净利落。注意，CONCAT 是 2012 版本才引入的，老项目如果用 2008/2008 R2，恐怕只能手动 ISNULL 了。

另外还有一个老开关 SET CONCAT_NULL_YIELDS_NULL，默认 ON，也就是加号遇到 NULL 结果是 NULL；如果你把它改成 OFF，加号遇到 NULL 就会按空串处理。但我不建议动它，因为这是会话级设置，很容易影响同一会话里的其他查询，带来一堆隐蔽问题。与其去改开关，不如从代码上换一种拼接方式。

3.3 ORDER BY、DISTINCT、GROUP BY中的NULL处理

聚合之外，排序和分组对 NULL 也有自己的规则。

ORDER BY 里，SQL Server 默认把 NULL 当作最小值，也就是说按某个可空字段升序排列时，NULL 排在最前面；降序排列时，NULL 排在最后面。这个行为跟 Oracle 不一样，Oracle 默认 NULL 最大，两个数据库排序结果不同，跨库开发时要注意。

想把 NULL 强制排到末尾，用 CASE 手动指定优先级：

sql复制SELECT 姓名, 手机号
FROM 客户表
ORDER BY CASE WHEN 手机号 IS NULL THEN 1 ELSE 0 END, 手机号;

GROUP BY 对 NULL 的态度则是：所有 NULL 归为一组。也就是说，一条字段有 50 行是 NULL，GROUP BY 会生成一个 NULL 分组。这个分组在报表里显示为空白行，经常被业务同事追问“这一行是什么”，需要你在开发时主动转成有业务含义的文案，比如 ISNULL(字段, N'未填写')，再用它去做分组显示。

DISTINCT 对 NULL 的处理也值得记一笔：多个 NULL 值在 DISTINCT 结果里只保留一条。这其实对应了“NULL 不等于 NULL 但 DISTINCT 仍然去重”的现象。理解上没有啥大问题，但写去重统计的时候要认清：SELECT DISTINCT 列 的结果里，NULL 只会出现一次。

4. 建表、索引、JOIN、应用层：NULL的完整作战地图

4.1 建表与索引设计：唯一约束、默认值、可空列怎么选

建表时，可空列和 NOT NULL 列的取舍直接影响后续开发。一个常见误解是：唯一约束能保证列值不重复，所以 NULL 也不可能重复。但 SQL Server 的实际行为是：唯一索引/唯一约束列上允许多个 NULL。比如员工表的工号列允许 NULL，你插入三行工号都是 NULL 的数据，数据库不会报唯一性冲突，因为 NULL 不等于 NULL，每个 NULL 都是“未知”，无法判断是否重复。

这个特性在业务上有时是好事，比如“备用手机号”这种本来就可以不填的字段；但如果是订单号这类业务上必须唯一的字段，你就不能只靠唯一约束来兜底，还得加 NOT NULL 约束，或者在应用层做校验。

索引层面，NULL 值也会进入索引结构，所以“WHERE 列 IS NULL”在某些条件下可以用到索引。但一个更常见的坑是，开发者为了处理 NULL 写成了：

sql复制WHERE ISNULL(部门编号, 0) = 0

这种写法对索引非常不友好，因为它对列做了函数运算，会让优化器很难使用该列的索引。更好的改写方式是把逻辑展开：

sql复制WHERE 部门编号 = 0 OR 部门编号 IS NULL

当然，具体走不走索引还是看数据分布和统计信息，不能百分之百保证，但展开写法至少保留了“走索引”的可能性，而函数包裹写法基本是放弃索引。

4.2 JOIN场景：INNER JOIN搭不上，OUTER JOIN补出一堆NULL

JOIN 是 NULL 最容易引发“凭空丢数据”的场景之一。INNER JOIN 在匹配时，如果两边关联列的值是 NULL，这个 NULL 无法和任何值匹配，包括另一个 NULL。所以，两张表靠一个可空列关联时，只要一侧是 NULL，这一行就参与不了 JOIN 结果，行数直接变少。

而 LEFT JOIN 会把左表所有行都保留下来，右表没有匹配行的列就会是 NULL。你以为查出来的是“每个员工及其部门信息”，结果部门编号为 NULL 的员工，部门名称显示为 NULL，这就是 JOIN 带来的 NULL。此时要注意过滤条件的位置：

sql复制SELECT e.Name, d.DepartmentName
FROM Employee e
LEFT JOIN Department d ON e.DepartmentId = d.Id
WHERE d.DepartmentName = N'研发部';

这个写法因为 WHERE 里过滤了右表字段，那些右表为 NULL 的行全被过滤掉，LEFT JOIN 基本失去了意义。如果业务上想要“要求员工在研发部，并且未分配部门的员工也要能看到”，可以考虑把过滤条件写到 ON 里：

sql复制SELECT e.Name, d.DepartmentName
FROM Employee e
LEFT JOIN Department d ON e.DepartmentId = d.Id AND d.DepartmentName = N'研发部';

这个 ON 里的过滤只影响右表是否匹配，不会剔除左表行。两种写法结果差异很大，属于 JOIN 设计里的高频问题。

4.3 C#/Java传NULL：从DBNull.Value到参数化查询

数据库里的 NULL 传到应用层，也是个高频踩坑点，尤其是 C#。C# 的 DateTime 是值类型，不能直接赋 null，必须用 DateTime?（Nullable），数据库字段为 NULL 时，参数对象不能直接传 null，而是要传 DBNull.Value。

推荐写法：

csharp复制using (var cmd = new SqlCommand(sql, conn))
{
    cmd.Parameters.Add("@CreateTime", SqlDbType.DateTime).Value =
        createTime.HasValue ? createTime.Value : (object)DBNull.Value;
}

或者更简洁一点：

csharp复制cmd.Parameters.Add("@CreateTime", SqlDbType.DateTime).Value =
    (object)createTime ?? DBNull.Value;

读取侧也一样。SqlDataReader 读取可空字段时，取出来之前要判断：

csharp复制int ord = reader.GetOrdinal("CreateTime");
DateTime? createTime = reader.IsDBNull(ord) ? null : (DateTime?)reader.GetDateTime(ord);

Java 侧对应的是 PreparedStatement 的 setNull：

java复制pstmt.setNull(3, Types.DATE);

读取时用 rs.getDate("col") == null 判断。

另外还有一个容易犯的错：把字符串 "NULL" 拼进 SQL 里，或者把 C# 的 null 直接 Add 给参数。前者会把 "NULL" 当成普通字符串存进数据库；后者会收到类型转换异常。无论哪种，都会让数据变得不可信。建议在数据访问层统一封装一个“值或 DBNull”的转换方法，项目里所有写参数的地方都走同一个入口，能省掉不少低级问题。

4.4 ISNULL和COALESCE到底选哪个

ISNULL 和 COALESCE 都能把 NULL 替换成默认值，但它们有几个关键差异。

ISNULL 是 SQL Server 专有函数，只有两个参数，返回类型以第一个参数的类型为准。这个特性会带来一个隐蔽的截断问题：

sql复制SELECT ISNULL(NULL, 0.5) AS result;

第一个参数类型是 int，第二个参数 0.5 会被转换成 int，结果是 0，而不是 0.5。COALESCE 是 ANSI 标准函数，可以传多个参数，返回类型取参数列表中优先级最高的类型，所以：

sql复制SELECT COALESCE(NULL, 0.5) AS result;

结果是 0.5，不会截断。如果你要跨数据库兼容，用 COALESCE；如果你只在本库用，并且明确想要“以第一个参数类型为准”，用 ISNULL 也没问题，但要注意别踩类型优先级和截断的坑。

参数数量上，ISNULL 只有两个参数，COALESCE 可以一次性传多个：

sql复制SELECT COALESCE(手机号, 紧急联系人手机号, N'无联系方式') FROM 客户表;

这种多级兜底的场景 ISNULL 得写嵌套才做得到。另外，SQL Server 文档提到 ISNULL 对表达式只计算一次，而 COALESCE 理论上可能对表达式计算多次，但在大多数简单的列值场景下影响很小，不用过度担心。

5. 常见问题速查与排查技巧

5.1 NULL问题速查表

5.2 快速验证：用几条SQL把NULL情况摸清

遇到疑似 NULL 引发的问题，我一般先跑这几条 SQL 把表里的 NULL 分布摸清楚：

sql复制-- 1. 看统计：每一列的 NULL 数量
SELECT
    COUNT(*) AS total_rows,
    SUM(CASE WHEN col1 IS NULL THEN 1 ELSE 0 END) AS col1_null_count,
    SUM(CASE WHEN col2 IS NULL THEN 1 ELSE 0 END) AS col2_null_count
FROM 表名;

-- 2. 看数据样例：到底哪几行有问题
SELECT * FROM 表名 WHERE col1 IS NULL OR col2 IS NULL;

-- 3. 看是不是 JOIN 后丢的行
SELECT a.Id, b.Name
FROM 左表 a
LEFT JOIN 右表 b ON a.key = b.key
WHERE b.Id IS NULL;

这三板斧下来，大多数 NULL 导致的“丢数据”“空结果”“统计对不上”问题都能定位到根因。之后再根据具体函数行为选择修复方案。

5.3 一些可以一开始就做好的“防御”设计

排查问题很重要，但从源头减少 NULL 带来的麻烦更值得投入。我在项目里经常推动几件事：

第一，关键业务字段能 NOT NULL 就 NOT NULL。金额、数量、状态这类字段，如果有业务默认值，直接给 DEFAULT 0 或 DEFAULT'初始状态'，让数据不得为空。这个习惯能省掉大量 ISNULL 兜底代码。

第二，可空字段要有清晰的业务语义。比如“备注”“扩展信息”字段允许 NULL 很正常，但“员工绩效”这种要参与计算的字段，最好从一开始就明确缺省值，否则后续每个报表都要处理一次 NULL，成本很大。

第三，应用层和数据库层统一约定。C# 实体类用可空类型，比如 int?、DateTime?；传输到数据库时明确转 DBNull.Value。不要在代码里造“魔数”，比如用 1900-01-01 表示“没有日期”，用 -1 表示“未知”，这类魔数会在未来某个时间点咬你一口。

第四，写报表查询时，先用 5.2 的 SQL 看一下关键列里有多少 NULL，再决定统计口径。这比写完后被业务方拿着错误数据找上门要省心得多。

这块内容如果多展开，还能聊过滤索引、稀疏列、统计信息对 NULL 的估算，但日常开发里把上面几条做到，已经能规避掉八成以上 NULL 引发的故障。

最后说几句个人习惯。我现在写任何查询，只要结果和预期对不上，第一件事不是怀疑索引，而是先跑一条 SELECT COUNT(1) FROM 表名 WHERE 关键列 IS NULL，看看 NULL 到底有多少。很多“诡异”问题，查到最后都是 NULL 在背后捣鬼。NULL 不是 bug，但看不见 NULL 的代码，早晚会变成 bug。