having不能直接过滤null，需用count()或coalesce确保逻辑正确；sum/avg等在空组返回null，而count(*)永非null；跨库兼容应避免依赖默认补0行为。
HAVING 不能直接过滤 NULL，得先让聚合结果可判断
SQL 中 HAVING 是对 GROUP BY 后的分组结果做筛选，但它本身不“生成”值——如果聚合函数（比如 COUNT()、SUM()）在某组里返回 NULL，那 HAVING col IS NOT NULL 看似合理，实际可能失效，因为很多聚合函数默认忽略 NULL 输入，但结果为 NULL 通常只发生在整组全为 NULL 或使用了 AVG()/SUM() 等在空集上未定义的情况。
常见错误现象：HAVING SUM(amount) IS NOT NULL 在某些数据库（如 PostgreSQL）中对空组返回 NULL，但 MySQL 默认返回 0，行为不一致；更隐蔽的是，COUNT(*) 永远不为 NULL，而 COUNT(col) 对全 NULL 组返回 0，不是 NULL，所以用 IS NOT NULL 判断毫无意义。
- 确认聚合函数是否真会输出
NULL：只有SUM()、AVG()、MAX()、MIN()在组内无非空行时才返回NULL；COUNT(*)和COUNT(expr)永远返回整数 - 优先用
IS NOT NULL判断聚合字段本身，而不是依赖函数返回值语义 - 若需排除“无有效数据”的组，更稳妥的方式是搭配
COUNT()：例如HAVING COUNT(col) > 0表示该组至少有一行col非空
MySQL 和 PostgreSQL 对空组聚合的处理差异必须显式处理
MySQL 在 GROUP BY 后对空组（比如 LEFT JOIN 右侧无匹配）执行 SUM() 时默认返回 0，而 PostgreSQL 返回 NULL。这意味着同一句 HAVING SUM(sales) != 0 在两个库中行为不同——MySQL 会保留空组（因为 0 != 0 为假），PostgreSQL 则因 NULL != 0 为未知（UNKNOWN），被 HAVING 当作不满足条件而过滤掉。
- 跨库兼容写法：用
HAVING SUM(sales) IS NOT NULL AND SUM(sales) != 0 - 更清晰的做法是提前用
COUNT()控制逻辑：例如HAVING COUNT(sales) > 0 AND SUM(sales) != 0，明确表达“有销售记录且总和非零” - 避免依赖数据库默认补
0的行为，尤其在迁移或联合查询场景下
WHERE 和 HAVING 的分工错位会导致空值漏判
很多人试图用 WHERE col IS NOT NULL 来“提前过滤空值”，但这只能筛掉原始行，无法控制聚合后是否为空组。比如对订单表按用户分组，想排除“没有任何有效金额订单”的用户，仅靠 WHERE amount IS NOT NULL 还不够——如果某用户所有 amount 都是 NULL，那这组在 GROUP BY 后依然存在，只是 SUM(amount) 为 NULL，必须靠 HAVING 处理。
-
WHERE过滤的是输入行，HAVING过滤的是分组结果 - 如果目标是“排除聚合后为 NULL 的组”，
WHERE做不了这件事，硬加只会让逻辑变模糊 - 典型误写：
WHERE SUM(amount) IS NOT NULL—— 直接报错，因为聚合函数不能出现在WHERE子句中
用 COALESCE 包裹聚合结果再判断更可控
当业务逻辑明确要求“把空聚合转成某个默认值再比较”时，COALESCE(SUM(amount), 0) 比裸写 SUM(amount) 更安全。它把 NULL 统一转为 0，后续用 > 0 或 != 0 就不会因三值逻辑（NULL 比较结果为 UNKNOWN）意外丢数据。
- 推荐写法：
HAVING COALESCE(SUM(amount), 0) > 0 - 注意性能：
COALESCE本身开销极小，但别在大表上对未索引字段反复计算 - 如果聚合字段本身允许为
0且业务上需区分“真实零值”和“无数据”，那就不能用COALESCE(..., 0)，得回到IS NOT NULL+ 显式计数的组合判断
真正容易被忽略的点是：聚合结果为 NULL 不一定代表“没数据”，也可能是字段类型隐式转换失败、数值溢出、或数据库版本特定行为。动手前先 SELECT GROUP BY ... , SUM(col), COUNT(col), COUNT(*) 看一眼各组的实际输出，比死磕 HAVING 条件更高效。
