having后可写count()=0，但逻辑上无效，因无数据的组根本不会进入分组结果；真正需防范的是where过早过滤导致本应存在的组消失，应将关联条件移至left join的on子句而非where。

HAVING 之后不能直接写 COUNT() = 0 这类条件？

能写，但多数时候你看到结果为空，不是语法错，而是逻辑反了。HAVING 是对分组后的聚合结果过滤，而 COUNT() 统计的是每组的行数——如果某组根本没数据，它压根就不会出现在分组结果里，自然也进不了 HAVING 的筛选范围。所以“过滤掉聚合结果为零的记录”，真正要防的其实是：本该有数据的组，因 WHERE 过滤过早，导致分组后 COUNT() 变成 0。

WHERE 和 HAVING 的执行顺序决定了谁该拦谁

WHERE 在分组前过滤原始行，HAVING 在分组后过滤聚合结果。想保留“有用户但无订单”的客户，却在 WHERE 里写了 order_date IS NOT NULL，那这些客户从第一步就被筛掉了，后面 COUNT(orders.id) 永远不会是 0——它干脆没机会算。

• 需要“有客户、无订单”这类记录？把关联条件移到 ON（用 LEFT JOIN），别塞进 WHERE
• 只想看至少下过 1 单的客户？HAVING COUNT(orders.id) >= 1 就够，不用绕弯
• 真要排除 COUNT = 0 的组？先确认这组是否本应存在——否则 HAVING COUNT(*) > 0 等价于没写

常见错误：LEFT JOIN + WHERE 导致 HAVING 失效

这是最典型的陷阱。例如：

SELECT c.id, COUNT(o.id)
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.status = 'paid'  -- ❌ 这里把 NULL 行全干掉了
GROUP BY c.id
HAVING COUNT(o.id) > 0;

这个 WHERE 实际上把所有 o.id IS NULL 的客户行都剔除了，LEFT JOIN 形同虚设。正确做法是把条件挪到 ON 子句：

SELECT c.id, COUNT(o.id)
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'paid'
GROUP BY c.id
HAVING COUNT(o.id) > 0;

聚合值为 NULL 时 COUNT() 不等于 0，但 SUM()/AVG() 可能是

COUNT(column) 会跳过 NULL，但只要该组至少有一行（哪怕 column 全是 NULL），COUNT(*) 仍大于 0；而 SUM(price) 或 AVG(score) 在整组 price 全为 NULL 时返回 NULL，不是 0。所以用 HAVING SUM(price) = 0 会漏掉那些“有订单但金额全为 NULL”的组。

• 检查是否真为 0：用 HAVING COALESCE(SUM(price), 0) = 0
• 区分“无数据”和“数据为 NULL”：HAVING COUNT(price) = 0 表示 price 列全空，HAVING SUM(price) IS NULL 表示有行但 price 全 NULL

实际业务中，“聚合结果为零”的背后往往是 JOIN 方式或 WHERE 位置选错了，而不是 HAVING 写得不够狠。