having 必须在 group by 之后执行，因其作用对象是分组后的聚合结果而非原始行；where 过滤行，having 过滤组，二者执行阶段不同、不可互换，且 having 中可使用聚合函数而 where 不可。
HAVING 必须在 GROUP BY 之后执行，因为它的作用对象是分组后的结果集
HAVING 不是对原始行做判断，而是对每个分组聚合后产生的“一行一组”结果做筛选。比如你用 GROUP BY department，数据库会先按部门把员工数据归成若干组，再对每组算出 COUNT(<em>)</em>、AVG(salary) 等值；只有这时，HAVING COUNT() > 5 才有意义。如果 HAVING 放在 GROUP BY 前，这些聚合值根本还没算出来，语法上就无法解析。
-
HAVING中能直接写COUNT(*)、AVG(price)，但WHERE里写会报错 - 没有
GROUP BY就用HAVING，多数数据库会允许但逻辑退化（等价于WHERE），MySQL 甚至可能隐式忽略分组语义 - 书写位置也受约束：必须紧接在
GROUP BY后、ORDER BY前，否则触发语法错误（如 PostgreSQL 直接拒绝，MySQL 可能容错但不推荐）
WHERE 和 HAVING 的分工不是可选，而是执行阶段决定的硬性限制
WHERE 过滤的是 FROM 输出的原始行，HAVING 过滤的是 GROUP BY 输出的分组行。两者不能互换，不是“习惯问题”，是 SQL 执行模型强制划分的边界。
-
WHERE salary > 5000→ 每行员工工资单独判断，过滤掉低薪员工后再分组 -
HAVING AVG(salary) > 5000→ 先按部门分组、算出每个部门平均工资，再筛掉平均工资 ≤ 5000 的部门 - 如果把
AVG(salary)写进WHERE，数据库会在分组前尝试计算聚合，直接报错：ERROR 1140: In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column
ORDER BY 为什么不能直接引用 HAVING 中的聚合表达式？
因为 ORDER BY 在 SELECT 之后执行，而 SELECT 子句决定了最终结果集的列结构。即使 HAVING AVG(salary) > 5000 用了 AVG(salary)，只要 SELECT 里没显式写出它（或给它起别名），ORDER BY 就找不到这个字段。
- 错误写法：
SELECT department FROM emp GROUP BY department HAVING AVG(salary) > 5000 ORDER BY AVG(salary)→ 报错：Unknown column 'AVG(salary)' in 'order clause' - 正确写法：
SELECT department, AVG(salary) AS avg_sal FROM emp GROUP BY department HAVING avg_sal > 5000 ORDER BY avg_sal - 或用位置序号：
ORDER BY 2（前提是AVG(salary)是SELECT中第二列）
GROUP BY 后的 SELECT 列表有强约束，直接影响 HAVING 能否合法使用
SQL 标准要求：出现在 SELECT 列表中的非聚合列，必须也在 GROUP BY 中声明。否则数据库无法确定该列在每组中取哪个值——这和 HAVING 是否可用无关，但会间接导致逻辑混乱。
- 允许：
SELECT department, COUNT(<em>) FROM emp GROUP BY department HAVING COUNT(</em>) > 10 - 不允许（标准 SQL 报错）：
SELECT department, name, COUNT(<em>) FROM emp GROUP BY department HAVING COUNT(</em>) > 10→name未被分组也未聚合 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，会拦截这类写法；旧版本可能返回随机name，结果不可靠
真正容易被忽略的点是：HAVING 的存在本身不改变 SELECT 输出结构，它只过滤分组；而能否在 ORDER BY 或 SELECT 中复用某个聚合表达式，完全取决于那个表达式是否已作为列显式出现——不是“写过就算数”，而是“输出了才算数”。
