where不能用count()、sum()等聚合函数，因其在group by前执行，只能访问原始列；having才用于分组后筛选聚合结果，且必须跟在group by后。
WHERE 不能用 COUNT()、SUM() 这类函数，一写就报错
错误现象：WHERE COUNT(*) > 5 或 WHERE AVG(salary) > 6000 直接语法报错。不是数据库版本问题，是 SQL 执行逻辑决定的——这些聚合值在 WHERE 阶段根本还没算出来。
原因很简单：WHERE 在 GROUP BY 之前执行，它只看到单条原始记录。你让它判断“这一行的 COUNT 是多少”，它只能回你一句“没这东西”。
- 能用的字段：原表里真实存在的列，比如
status、created_at、user_id - 不能用的：任何聚合函数、SELECT 中定义的别名（如
AS total）、未出现在 GROUP BY 中的非聚合列 - 典型误用场景：把本该写在 HAVING 的条件硬塞进 WHERE，比如想筛“订单总数超 10 的客户”，却写成
WHERE COUNT(order_id) > 10
HAVING 必须跟在 GROUP BY 后面，单独用很危险
HAVING 不是 WHERE 的替代品，它专为分组后筛选而生。没有 GROUP BY，HAVING 就失去意义——它要筛的是“组”，不是“行”。
某些数据库（如 MySQL）允许 HAVING 单独出现（隐式把整张表当一个组），但这属于兼容性行为，语义模糊且跨库不一致。
- 安全写法：只要用了
HAVING，前面必须有GROUP BY，哪怕只按一个常量分组（如GROUP BY 1）也不推荐 - 可引用的内容：聚合表达式（
COUNT(*)）、SELECT 中的别名（AS cnt）、GROUP BY 字段（dept） - 反模式示例：
SELECT * FROM orders HAVING SUM(amount) > 10000—— 逻辑不清，MySQL 可能跑通，PostgreSQL 直接拒绝
WHERE 和 HAVING 经常一起用，顺序不能乱
真实业务查询往往需要两层过滤：先缩小原始数据集，再对分组结果做门槛控制。这时 WHERE 和 HAVING 是搭档，不是对手。
执行顺序固定为：FROM → WHERE → GROUP BY → HAVING。这个顺序决定了谁快、谁准、谁省资源。
-
WHERE越早过滤越好：比如查“2025 年下单且总金额超 5 万的客户”，WHERE order_date >= '2025-01-01'能直接跳过历史数据，避免无谓聚合 -
HAVING只负责最终拍板：HAVING SUM(amount) > 50000是在分组算完每个客户的总金额后才生效 - 性能陷阱：把时间范围、状态码这类单行可判的条件挪到 HAVING 里，等于让数据库先聚合全部数据再丢弃，慢且浪费内存
别名在 HAVING 里能用，在 WHERE 里不能用
这是容易被忽略但很实用的细节。SELECT 列表中用 AS 定义的别名，在 WHERE 中不可见，但在 HAVING 中可以直接用。
例如：SELECT dept, AVG(salary) AS avg_sal FROM emp GROUP BY dept HAVING avg_sal > 6000 是合法的；但 WHERE avg_sal > 6000 一定报错。
- 原因：WHERE 在 SELECT 执行前就结束了，别名还没诞生；HAVING 在 SELECT 之后、结果集已生成，别名已绑定
- 好处：让 HAVING 条件更易读，不用重复写长聚合表达式
- 注意点：别名必须基于 GROUP BY 字段或聚合表达式，不能是未分组也未聚合的裸列（如
HAVING name = 'Alice'会失败）
实际写的时候，先问自己一句：这个条件是靠单条记录就能判断，还是得等分组+算完总和/平均值才能知道？前者扔 WHERE，后者交 HAVING。顺序错了，轻则报错，重则查出错数据还看不出毛病。
