WHERE在分组前过滤行，HAVING在分组后过滤组；HAVING可使用聚合函数且必须配合GROUP BY或用于全局聚合，但不能引用未聚合的非分组字段或SELECT别名（MySQL 5.7不支持），也不能替代WHERE做前置条件过滤。
WHERE 和 HAVING 的根本区别在哪
WHERE 在分组前过滤行，HAVING 在分组后过滤组。如果你写了 HAVING 却没用 GROUP BY，MySQL 会把它当作全局聚合处理（即整个结果集算作一组），这时 HAVING 才能生效；否则直接报错或逻辑错乱。
常见错误现象：Unknown column 'xxx' in 'having clause' —— 因为 HAVING 不能引用 SELECT 别名（除非是 MySQL 8.0+ 且在派生表/CTE 中），也不能引用未聚合的非 GROUP BY 字段。
- 必须配合
GROUP BY使用，或用于无分组的聚合查询（如SELECT COUNT(*) HAVING COUNT(*) > 10） -
HAVING可以使用聚合函数（COUNT()、SUM()、AVG()等），WHERE 不可以 - 性能上，
HAVING是在临时分组结果上再扫描，数据量大时比WHERE更慢
怎么写一个带 HAVING 的合法分组筛选
典型场景：查订单数超过 5 的客户，或平均订单金额高于 200 的城市。
SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING order_count > 5;
注意：order_count 是别名，MySQL 5.7 默认不支持在 HAVING 中直接用别名，得写成 HAVING COUNT(*) > 5；MySQL 8.0+ 在大多数情况下允许，但为兼容性建议优先用原始表达式。
- 如果要按多个条件筛选，用
AND/OR连接，例如HAVING COUNT(*) >= 3 AND AVG(amount) > 100 - 字段必须出现在
GROUP BY中，或被聚合函数包裹，否则 MySQL 会报sql_mode=only_full_group_by错误 - 避免在
HAVING中写复杂子查询——它会在每组结果上执行，容易拖慢速度
HAVING 能不能替代 WHERE？什么情况下会出问题
不能随意替代。比如你想排除状态为 'cancelled' 的订单，必须用 WHERE status != 'cancelled'，而不是塞进 HAVING。
原因：WHERE 先执行，减少参与分组的数据量；而 HAVING 是对已分组结果再过滤，如果把本该前置过滤的条件放 HAVING，会导致无效分组计算，浪费资源甚至逻辑错误。
- 错误写法：
SELECT user_id, COUNT(*) FROM logs GROUP BY user_id HAVING action = 'login'——action未聚合也未在 GROUP BY 中，语法非法 - 正确做法：先
WHERE action = 'login'，再分组统计 - 特殊例外：当你要筛的是“某组是否包含某个值”，可用
HAVING SUM(action = 'error') > 0，但这是利用布尔转整数的技巧，不是常规替代
MySQL 8.0+ 中 HAVING 和窗口函数一起用要注意什么
不能直接在 HAVING 中用窗口函数。窗口函数只能出现在 SELECT 或 ORDER BY 中，HAVING 属于分组阶段，早于窗口计算时机。
想实现“筛选出累计销售额前 3 的品类”，不能写 HAVING ROW_NUMBER() OVER (ORDER BY SUM(sales) DESC) —— 会报错 <code>Window function is not allowed in HAVING clause。
- 解决方案：用 CTE 或子查询先把窗口结果算出来，再在外层用 WHERE 过滤
- 例如：
WITH ranked AS (SELECT category, SUM(sales) s, ROW_NUMBER() OVER (ORDER BY SUM(sales) DESC) rn FROM sales GROUP BY category) SELECT * FROM ranked WHERE rn - 别指望 HAVING 能简化这类逻辑——它的定位就是“对 GROUP BY 结果做二次断言”，不是通用筛选入口
实际用 HAVING 时，最易忽略的是它和 SQL 执行顺序的绑定关系：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。一旦搞混这个顺序，要么报错，要么结果不对，而且不容易排查。
