group by 不会丢失 null 分组，而是将所有 null 归为一组且显示为空白；需用 ifnull 或 coalesce 显式标记，并验证原始 null 量与分组中 fallback 值计数是否一致。
GROUP BY 本身不会“丢失”空分组，但 NULL 值会被统一归为一组且不可见——问题出在你没主动把它当作一个合法分组值来对待。
为什么 GROUP BY 后看不到 NULL 分组？
MySQL（及标准 SQL）把所有 NULL 视为相等，并强制归入同一组。但它不等于任何值，也不参与 = 或 IN 判断，所以你用 WHERE category IS NULL 能查到数据，但 GROUP BY category 的结果里那一行可能被你忽略——它就叫 NULL，不是字符串 'NULL'，排序时还常排最前或最后，肉眼难定位。
- 执行
SELECT category, COUNT(*) FROM products GROUP BY category，结果中那行NULL可能夹在中间、没标头、导出后变空格 - 如果前端按字符串渲染，
NULL显示为空白，你以为“漏了”，其实是它在那儿但没被识别 -
ORDER BY category会让NULL扎堆排头，若你只看前几页，根本看不到
用 IFNULL() 或 COALESCE() 显式标记 NULL 分组
别依赖数据库默认行为，把 NULL 映射成可读、可筛选的明确值。注意函数选择和写法：
- MySQL 用
IFNULL(category, 'unknown')；PostgreSQL/SQL Server 用COALESCE(category, 'unknown') -
GROUP BY必须写完整表达式：GROUP BY IFNULL(category, 'unknown')，而不是GROUP BY cat（哪怕你在SELECT里写了AS cat） - 数值列慎用字符串兜底，比如
IFNULL(price, -1)比IFNULL(price, 'missing')更安全，避免隐式类型转换干扰索引或聚合 - 若字段可能含空格或全角空白，先
TRIM()再判空：IFNULL(TRIM(category), 'empty')
当 NULL 有多种业务含义时，别硬塞进一个 fallback 值
一个 'unknown' 标签掩盖不了数据质量差异。先确认 NULL 成因，再决定是否拆分：
-
category IS NULL AND source = 'api_v2'→ 表示接口未返回，标为'api_missing' -
category IS NULL AND status = 'draft'→ 表示草稿未填写，标为'pending_input' - 用
CASE WHEN区分逻辑：CASE WHEN category IS NULL AND updated_at - 聚合后加注释，例如：
-- 'api_missing': field omitted by upstream, not a data error
检查是否真丢了分组：先查原始分布，再比对分组结果
所谓“丢”，往往只是你没看到。验证步骤要闭环：
- 查原始 NULL 量：
SELECT COUNT(*) FROM products WHERE category IS NULL - 查分组结果中对应项：
SELECT * FROM (SELECT IFNULL(category, 'unknown') AS g, COUNT(*) c FROM products GROUP BY IFNULL(category, 'unknown')) t WHERE g = 'unknown' - 两数必须相等；若不等，说明有其他过滤条件（如
WHERE或JOIN）提前剔除了部分NULL行 - 开
ONLY_FULL_GROUP_BY模式（SELECT @@sql_mode确认）能暴露 SELECT 和 GROUP BY 字段不一致导致的静默截断
真正容易被忽略的是：NULL 分组不是技术问题，是数据契约断裂的信号。你用 IFNULL() 把它标出来，只是让问题可见；要不要修复上游填值逻辑，才是关键决策点。
