where不能在group by之后使用，因其执行顺序在分组前（from→where→group by→having），无法访问count(*)等聚合结果；必须用having筛选分组后的统计值，且having只能引用group by列或聚合表达式。
WHERE 不能用在 GROUP BY 之后，因为执行顺序不对
SQL 的执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。这意味着 WHERE 在分组前就过滤了原始行，根本看不到聚合结果（比如 COUNT(*)、AVG(price)），自然无法对分组后的统计值做判断。
常见错误现象：WHERE COUNT(*) > 5 会直接报错，MySQL 提示 Invalid use of group function，PostgreSQL 报 aggregate functions are not allowed in WHERE。
所以，只要条件里出现聚合函数或需要基于分组结果判断，就必须用 HAVING。
HAVING 必须跟在 GROUP BY 后面，且只能写聚合字段或 GROUP BY 列
HAVING 的作用对象是“分组后的结果集”，它能访问的字段只有两类：一是出现在 GROUP BY 中的列（如 category），二是聚合表达式（如 COUNT(*)、MAX(created_at)）。如果写了一个既没分组也没聚合的普通列（比如 WHERE name = 'Alice' 那种写法），会报错。
实操建议：
- 先确认
SELECT和GROUP BY中的列是否一致——例如SELECT user_id, COUNT(*) FROM orders GROUP BY user_id，那么HAVING可以用user_id或COUNT(*) - 如果想按某字段筛选但又不想分组，得把它加进
GROUP BY，否则 SQL 引擎不知道该拿哪个值来比 - MySQL 有个宽松模式允许
SELECT a, b, COUNT(*) GROUP BY a HAVING b > 10，但这不可靠，其他数据库直接拒绝，别依赖
HAVING 和 WHERE 联合使用时，优先级和性能差异明显
典型场景：查“每个部门中薪资高于 8000 的员工数超过 3 人的部门”。这里有两个层级的过滤：
-
WHERE salary > 8000先筛出高薪员工（减少后续分组数据量） -
HAVING COUNT(*) > 3再筛出满足人数要求的部门（必须在分组后）
错误写法：HAVING salary > 8000 —— salary 不在 GROUP BY 中，也不是聚合值，语法非法。
性能影响：把能提前过滤的条件尽量放进 WHERE，避免无谓分组；HAVING 是对已分组结果再扫描，数据量越大越慢。
示例（标准写法）：
SELECT dept, COUNT(*) AS cnt FROM employees WHERE salary > 8000 GROUP BY dept HAVING COUNT(*) > 3;
NULL 值和空分组容易被忽略，HAVING 行为和预期可能不一致
HAVING 对 NULL 的处理和 WHERE 一样：条件为 UNKNOWN 时整行被排除。但问题常出在聚合函数上——比如 COUNT(column) 忽略 NULL，而 COUNT(*) 统计所有行。
容易踩的坑：
-
HAVING AVG(score) >= 90：如果某组所有score都是NULL，AVG()返回NULL，该组被跳过，不会出现在结果里 -
HAVING COUNT(*) = 0永远不成立，因为没数据就不会生成分组行；真要查“没人报名的课程”，得用LEFT JOIN+IS NULL - 某些数据库（如 older SQLite）对空字符串和
NULL区分不严格，测试时注意数据实际类型
复杂点在于：你得清楚自己是在筛“分组是否存在”，还是筛“分组内聚合值是否达标”——前者靠 GROUP BY + HAVING，后者往往要嵌套查询或窗口函数配合。
