NULL值在GROUP BY里到底怎么处理？很多人在写SQL时都会在这个问题上栽跟头。先说一个常见的误区：NULL在GROUP BY里会被自动聚成一组——这不是bug，是标准行为。但很多人误以为它“不参与分组”或者“该被填掉”，结果写出SELECT NVL(status, 'pending'), COUNT(*) FROM orders GROUP BY status这种无效写法。猜猜怎么着？NULL照样单独出一行，完全没达到预期效果。
GROUP BY 里 NULL 怎么归到默认值里？
关键点只有一条：必须让分组字段本身不含NULL，而不是只在SELECT里做表面功夫。否则分组逻辑照旧，NVL或COALESCE的结果只是显示用，对分组没有任何影响。
GROUP BY子句里得显式包裹：写成GROUP BY COALESCE(status, 'unknown')，别写GROUP BY status- MySQL用
IFNULL(status, 'unknown')，PostgreSQL/Oracle用COALESCE(status, 'unknown')——跨库迁移时这里很容易报错，务必留意 - 多个字段都可能为NULL？每个都要套：
GROUP BY COALESCE(a, 'x'), COALESCE(b, 'y') - 如果字段是表达式，比如
UPPER(name)，得对整个表达式套：GROUP BY COALESCE(UPPER(name), 'UNKNOWN')
COUNT(*) 和 COUNT(col) 在 NULL 分组里为啥差很多？
这是最常踩的坑，没有之一。同一组NULL数据，COUNT(*)算的是行数，COUNT(status)却返回0——原因很简单，后者会跳过所有NULL值。
- 想统计“status为空的订单数”，别写
COUNT(status)，要写COUNT(*)或SUM(CASE WHEN status IS NULL THEN 1 ELSE 0 END) COUNT(NVL(status, 'x'))其实没什么用：NVL把NULL变成字符串后，COUNT照样计数，结果和COUNT(*)一样- 真要“把NULL当某个值参与计数”，得用条件聚合：
COUNT(CASE WHEN status IS NULL THEN 1 END)
ORDER BY 里怎么让 NULL 排最后？
NULLS LAST看起来干净利落，但MySQL 5.7及更早版本根本不认，直接报ERROR 1064。这时候就得另想办法了。
- PostgreSQL/Oracle/SQL Server 2012+支持
ORDER BY col NULLS LAST - MySQL 5.7必须模拟：
ORDER BY IF(col IS NULL, 1, 0), col - SQLite部分版本支持
NULLS LAST，但行为不太稳定，建议统一用IF或CASE表达式兜底 - 注意：如果
col是字符串且用了COLLATE，某些排序规则会覆盖NULLS LAST，实际NULL还是排在最前面
话说回来，真正麻烦的不是语法本身，而是业务语义——NULL到底代表“未填”“无效”还是“不适用”？同一个字段在不同场景下可能需要完全不同的处理方式：有时该归进default组，有时该单独统计，有时则直接过滤掉。别指望一个COALESCE能通吃所有情况。这，才是这个问题的真正痛点。
