having必须跟在group by后，用于分组后过滤；where在分组前过滤行，不可用聚合函数。having可引用select中的别名或聚合函数，但不可用未分组且非聚合字段。where应优先过滤以提升性能，null值在having中常导致分组被意外排除。
HAVING 必须跟在 GROUP BY 后面，不能替代 WHERE
WHERE 是在分组前过滤行，HAVING 是在分组后过滤分组结果。如果把条件写在 WHERE 里却想用聚合函数，MySQL 会直接报错 Invalid use of group function。
常见错误示例：SELECT department, COUNT(*) FROM employees WHERE COUNT(*) > 5 GROUP BY department; —— 这条语句语法非法，因为 COUNT(*) 在 WHERE 阶段还没计算出来。
正确写法必须先 GROUP BY，再用 HAVING：
SELECT department, COUNT(*) AS cnt FROM employees GROUP BY department HAVING cnt > 5;
HAVING 中能用别名，但不能用 SELECT 中未出现的字段
MySQL 允许在 HAVING 子句中直接使用 SELECT 列表里的列别名（如 cnt），这是它和标准 SQL 的一个差异，但要注意：这个别名必须真实出现在 SELECT 中。
-
HAVING cnt > 5✅ 可以，因为cnt是显式定义的别名 -
HAVING AVG(salary) > 8000✅ 可以，即使没起别名，聚合函数本身可被引用 -
HAVING hire_date > '2020-01-01'❌ 报错，hire_date没在GROUP BY中，也不在聚合结果里，无法参与分组后筛选
WHERE + HAVING 组合使用时，执行顺序决定性能
先 WHERE 过滤原始数据，再 GROUP BY 分组，最后 HAVING 筛选分组结果。这意味着：能放进 WHERE 的条件尽量放进去，减少分组的数据量。
比如查“2023 年入职、且平均薪资超 1 万的部门”：
SELECT department, AVG(salary) AS avg_sal FROM employees WHERE hire_date >= '2023-01-01' -- 先筛年份，大幅减小分组输入 GROUP BY department HAVING avg_sal > 10000;
如果把 hire_date 条件挪到 HAVING，MySQL 就得对所有历史数据分组后再过滤，效率明显下降。
NULL 值在 HAVING 中的处理容易被忽略
聚合函数对 NULL 的处理是默认忽略的，但 HAVING 自身的布尔表达式遇到 NULL 会判定为 false（即该分组被排除）。例如：
SELECT team, COUNT(*) FROM players GROUP BY team HAVING team IS NULL;
这条语句不会返回任何结果，除非 team 字段真有 NULL 值且被纳入了分组 —— 而这取决于 GROUP BY 是否允许 NULL 作为独立分组（MySQL 默认允许）。
更隐蔽的问题是：当聚合结果为 NULL（比如 AVG() 作用于全 NULL 列），HAVING avg_col > 100 整个表达式变成 NULL > 100，结果为 UNKNOWN，该分组照样被丢弃。这点不像 WHERE 那样常被测试覆盖，上线后容易漏数据。
