having必须跟在group by后，因它仅作用于分组后的聚合结果；直接join后加having会报error 1140，根本原因是未分组则无“组内聚合值”，count等函数无法计算。
HAVING 必须跟在 GROUP BY 后面，且条件里必须含聚合函数或分组字段；单独写 HAVING 或用它过滤单行数据，一定会报错或逻辑错误。
为什么直接 JOIN 后加 HAVING 会报 ERROR 1140？
根本原因是：HAVING 不是“通用筛选器”，它只对 GROUP BY 产出的分组结果起作用。没分组，就没有“组内聚合值”，COUNT 就无从计算。
- 执行顺序是
FROM→WHERE→GROUP BY→HAVING，HAVING在GROUP BY之后才生效 -
WHERE可以写o.status = 'paid'这种单行条件，但不能写COUNT(*) > 1 -
HAVING可以写COUNT(o.id) >= 3，但前提是前面有对应的GROUP BY u.id, u.name -
LEFT JOIN中，COUNT(o.id)会忽略NULL（即没订单的用户记为 0），而COUNT(*)把空行也算作 1 —— 选错就漏数据
GROUP BY 字段写不全会怎样？
比如查“每个用户的订单数 ≥ 3”，写了 GROUP BY u.id 却在 SELECT 里写了 u.name，MySQL 8.0+ 会直接报错：Expression #2 of SELECT list is not in GROUP BY clause。
- 这不是 bug，是 SQL 标准强制要求：所有非聚合字段都得出现在
GROUP BY中，否则数据库无法确定该取哪一行的name - 正确写法：要么只
SELECT u.id, COUNT(*)，要么GROUP BY u.id, u.name - PostgreSQL、Oracle、SQL Server 全部严格遵循此规则，不存在兼容侥幸
- 别依赖 MySQL 5.7 的宽松模式（
sql_mode关闭ONLY_FULL_GROUP_BY），上线后容易翻车
子查询里能直接写 HAVING 吗？
不能。标准 SQL 规定 HAVING 只能出现在顶层 SELECT 或完整独立查询中，否则报错 syntax error at or near "HAVING"。
- 常见错误写法：
SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5)—— PostgreSQL、MySQL 8.0+、SQL Server 都会失败 - 正确结构必须让
GROUP BY+HAVING自成一句完整查询：SELECT customer_id FROM (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5) AS t - 复杂场景推荐用 CTE：
WITH high_value_customers AS (SELECT customer_id, COUNT(*) AS order_cnt FROM orders GROUP BY customer_id HAVING COUNT(*) >= 3)，可读性高，优化器也更可控 -
HAVING条件里不能引用别名（如HAVING order_cnt >= 3会报错），必须用原始表达式HAVING COUNT(*) >= 3
想查重复数据的完整行，为什么不能只靠 HAVING？
HAVING 只能返回分组键和聚合结果，比如 SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1，最多输出 alice@example.com | 3。但业务通常要看到这三条记录的 id、name、created_at —— 这时 HAVING 本身做不到。
- 常见补救方案是子查询：
WHERE email IN (SELECT email FROM users GROUP BY email HAVING COUNT(*) > 1) - 注意
NULL：如果email允许为空，IN会跳过NULL行，得额外加OR email IS NULL并在子查询中处理 - 大表慎用
IN；更稳的方式是窗口函数：ROW_NUMBER() OVER (PARTITION BY email ORDER BY id)，然后筛rn > 1 - 别在子查询里
SELECT *—— 只要重复字段，否则可能触发类型不匹配或性能问题
真正容易被忽略的是执行顺序带来的字段可见性限制：WHERE 看不到聚合结果，HAVING 看不到未分组的非聚合字段，而 SELECT 别名在 HAVING 里又不可用 —— 这三层隔离不是设计缺陷，而是 SQL 语义严谨性的体现。
