NULL在GROUP BY中默认聚为一组，符合SQL标准；需用COALESCE或CASE显式转换以归入语义化类别，并确保SELECT与GROUP BY表达式一致，同时注意ORDER BY中NULL排序及聚合函数对NULL的处理差异。
GROUP BY 中 NULL 默认会聚成一组，但业务上常需显式归类
SQL 标准规定所有 NULL 值在 GROUP BY 中彼此相等，因此自动归为同一组——这不是 bug，是预期行为。问题在于：你看到的“NULL 组”可能代表“未填写”“接口未返回”或“校验失败”，而这些语义不该混在一起统计。
安全做法是提前把 NULL 显式转为有业务含义的占位值，且必须保证 SELECT 和 GROUP BY 中使用的表达式完全一致：
-
COALESCE(status, '待补充')最通用，但注意类型兼容：若status是整数，别用字符串占位（PostgreSQL 会报错，MySQL 可能静默转成 0） -
CASE WHEN status IS NULL THEN '未知' ELSE status::TEXT END更稳妥，能避免隐式转换，也方便后续加注释说明语义 - 别写
SELECT COALESCE(x, 'a') AS y GROUP BY y—— MySQL 允许，PostgreSQL 和标准 SQL 不认，换库就报错column "y" does not exist
ORDER BY 里不控制 NULL 位置，结果排序会因数据库而异
即使分组正确，ORDER BY department 在不同数据库中对 NULL 的默认排序位置完全不同：PostgreSQL / Oracle 升序时 NULL 排最后，MySQL 5.7 升序时排最前，SQL Server 行为又不同。靠默认值写出来的报表，在测试和生产环境可能顺序颠倒。
跨库安全的写法是用 CASE 模拟：
- 想让
NULL排最后（等效NULLS LAST）：ORDER BY CASE WHEN department IS NULL THEN 1 ELSE 0 END, department - 想让
NULL排最前（等效NULLS FIRST）：ORDER BY CASE WHEN department IS NULL THEN 0 ELSE 1 END, department - MySQL 8.0.22+、PostgreSQL、Oracle 支持原生
NULLS LAST，但上线前务必查版本：SELECT VERSION()或SELECT @@VERSION
聚合函数自动忽略 NULL，但整组全 NULL 时结果可能是 NULL 而非 0
COUNT(*) 统计所有行，COUNT(col)、SUM(col)、AVG(col) 全部跳过 NULL——这是标准行为，但容易引发误判：
- 如果某组
amount全是NULL，AVG(amount)返回NULL，前端可能渲染为空白，你以为漏数了，其实是真没值 -
COUNT(col)和COUNT(*)差异必须时刻绷着：前者只算非空，后者算全部；比如统计“有效订单数”该用前者，“总订单数”该用后者 - 要补 0，别用
COALESCE(AVG(col), 0)——它只改结果，不改分母；正确写法是COALESCE(SUM(col), 0) / NULLIF(COUNT(col), 0)，避免除零
别用 IFNULL() 一锅端，先确认 NULL 的真实成因
IFNULL()（MySQL）、COALESCE()（通用）、ISNULL()（SQL Server）只是语法工具，真正危险的是把不同原因的 NULL 强行塞进同一个占位值。
例如 region 列出现 NULL，可能意味着：
- 数据未录入（可归为“待分配”）
- API 接口未返回该字段（需上游修复）
- ETL 过程中校验失败被清空（应标为“invalid”并报警）
这时候统一写 IFNULL(region, 'other') 看似省事，实则掩盖数据质量问题。更合理的路径是：先查 SELECT region, COUNT(*) FROM t GROUP BY region，再结合日志或上游文档判断每类 NULL 的来源，最后决定是否拆成多个 CASE 分支处理。
复杂点往往不在 SQL 写法，而在要不要把“未填”和“填了但无效”当成同一类来统计——这个判断没法交给数据库，得人来定。
