在SQL Server的数据统计需求里，经常遇到按某个业务字段分组计数或求和的场景。如果这个字段在源数据里既可能出现NULL，也可能出现空字符串，那么默认的GROUP BY就会把它们视为两个互不相干的组。这种拆分往往不是业务想要的结果，因为空字符串和缺失值在很多语境下代表同一含义，比如用户没有填写昵称。要得到干净的报表，就必须在分组前把这两种状态合并成同一个值。
先来看一个最直观的现象。我们创建一张简单的会员表，并插入几条混合了NULL与空串的记录。执行不带任何处理的GROUP BY，会看到结果集中出现了两行维度。下面这段代码演示了这种默认行为：
CREATE TABLE Member (
Id INT IDENTITY PRIMARY KEY,
NickName NVARCHAR(50)
);
INSERT INTO Member (NickName) VALUES
('Alice'), (''), (NULL), (''), (NULL), ('Bob');
SELECT NickName, COUNT(*) AS Cnt
FROM Member
GROUP BY NickName;
-- 结果会包含 'Alice', 'Bob', '', NULL 四个组
从结果能明显看出，空字符串和NULL各自成组。对于前端展示或后续汇总，这种结构会让使用者困惑，也容易造成重复计算。很多刚接触SQL Server的人会直觉地想到用ISNULL函数把NULL变成空字符串，认为这样就能合并。但实际上，如果原字段里本身就有空字符串，ISNULL只能解决NULL那一端，空串依旧独立。
ISNULL的语法是ISNULL(表达式, 替换值)，当表达式求值为NULL时返回替换值，否则返回原值。它不会改变原本就是空串的行。因此单独使用ISNULL(NickName, '')，空串行仍然是空串，和由NULL转来的空串在值上相等，这时GROUP BY确实能合并；但如果有人用ISNULL(NickName, '未知')，空串行不会变成未知，还是单独一组。理解这一点是避免误用的关键。
用ISNULL与CASE WHEN做分组前统一化
如果确认业务上NULL和空串都代表未填写，最简单的写法是在SELECT和GROUP BY中同时使用ISNULL，把NULL映射为空串，然后依赖空串自身完成合并。示例如下：
SELECT ISNULL(NickName, '') AS NickGroup, COUNT(*) AS Cnt FROM Member GROUP BY ISNULL(NickName, ''); -- NULL与''都会归入 '' 组
这种写法在绝大多数报表查询里已经够用，而且ISNULL是SQL Server原生函数，执行效率不错。不过它有一个隐藏前提：你接受空串作为合并后的展示值。如果希望合并后用更有意义的文字，比如未填写，就需要CASE WHEN把所有情况覆盖。
CASE WHEN比ISNULL更灵活，能够显式判断空串和NULL。下面这段代码把二者都转成未填写，其余原样输出：
SELECT
CASE
WHEN NickName IS NULL OR NickName = '' THEN '未填写'
ELSE NickName
END AS NickGroup,
COUNT(*) AS Cnt
FROM Member
GROUP BY
CASE
WHEN NickName IS NULL OR NickName = '' THEN '未填写'
ELSE NickName
END;
从可读性看，CASE WHEN清楚地表达了业务规则，后期维护者一眼就能明白空串和NULL被同等对待。从性能角度，两种写法都会在分组前计算表达式，数据量很大时会有轻微CPU开销，但远比应用层先拉取再合并要高效。如果这类查询频繁，还可以考虑在表上建计算列并索引，把统一化动作固化。
空字符串与NULL在存储和索引上的差异
很多开发者以为空串和NULL在SQL Server里差不多，其实存储机制完全不同。NULL表示值未知，不占用实际数据字节，在行结构里只占用NULL位图中的一个标记。而空字符串是一个长度为0的合法字符串，仍然要走NVARCHAR的存储格式，只是字符数为0。这种差异导致在唯一索引、统计信息更新时，二者行为不一致。
例如对NickName建唯一索引，你可以插入一行NULL和一行空串而不报错，因为NULL不参与唯一性比较，空串则参与。这意味着在写入层如果不加约束，数据天然会分裂成两种状态。要在根源上减少分组麻烦，可以在表定义时使用约束：
CREATE TABLE Member2 (
Id INT IDENTITY PRIMARY KEY,
NickName NVARCHAR(50) NULL
CHECK (NickName <> '')
);
-- 禁止写入空串，只允许NULL或具体值
加上这个CHECK约束后，应用只能存NULL或真实昵称，分组时只需处理NULL即可，用ISNULL统一成某个默认值就够了。这种方式把清洗动作前置，查询侧逻辑最简单。缺点是历史表如果已经存在空串，需要先UPDATE清洗数据才能加约束。
另外在统计信息里，SQL Server对NULL有单独的密度值，对空串则作为普通字符串值统计。这会影响优化器对GROUP BY行数预估，如果空串极多而NULL极少，单纯用ISNULL转空串可能让预估偏差变小，但用CASE WHEN转成新值会让新值成为一个以前没出现过的高频值，首次统计可能不准。明白这些底层细节，才能评估统一化方案对整体性能的真实影响。
在复杂报表中组合统一化与其他聚合
实际业务往往不是单字段分组，而是按地区、渠道再加上昵称状态来交叉统计。这时统一化逻辑要套在更外层，且需注意别名复用。SQL Server不允许在GROUP BY里直接引用SELECT里的别名，所以要么重复表达式，要么用子查询或CTE包装一层。
下面用CTE把统一化提前做好，再和外层渠道表关联统计：
WITH CleanMember AS (
SELECT
ChannelId,
CASE
WHEN NickName IS NULL OR NickName = '' THEN '未填写'
ELSE NickName
END AS NickGroup
FROM Member
)
SELECT cm.ChannelId, cm.NickGroup, COUNT(*) AS Cnt
FROM CleanMember cm
GROUP BY cm.ChannelId, cm.NickGroup
ORDER BY cm.ChannelId, Cnt DESC;
使用CTE后，分组字段变得非常干净，后续如果要加SUM(amount)或者AVG(age)也不受影响。相比于在每一个报表SQL里重复写CASE WHEN，CTE或视图能集中管理规则，避免不同报表对空串和NULL理解不一致。
还有一种情况是前端导出Excel时希望NULL显示为空单元格，空串也显示为空，但数据库里仍要区分。此时就不该在查询里合并，而应在展示层处理，或者用报表工具的空值映射。数据库侧强行ISNULL会丢失信息，比如运维排查时无法区分到底是没填还是填了空。所以统一化不是银弹，只建议在纯汇总、且业务明确等同的场景使用。
总结来看，处理SQL Server分组字段里的空串与NULL，ISNULL能解决NULL端，但必须配合对空串的判断才能真正统一；CASE WHEN是最稳妥的写法；从架构上用约束禁止空串可一劳永逸。理解存储差异与统计信息行为，才能让分组统计既准确又高效。
SQL_ServerISNULL分组统计修改时间：2026-08-15 00:21:36