WHERE不能用聚合函数，正确做法是先GROUP BY再用HAVING过滤分组结果；HAVING后不可直接跟子查询，应将子查询前置为派生表或CTE；复杂条件需在子查询中完成行级过滤，再聚合筛选。
WHERE 不能用聚合函数，所以别硬写 WHERE COUNT(*) > 1
这是最常卡住人的地方：想筛出“订单数超过 5 的用户”，却在 WHERE 里直接写 COUNT(*) > 5，结果报错 ERROR: aggregate functions are not allowed in WHERE。因为 WHERE 执行时还没分组，COUNT 根本没意义。
正确做法是先 GROUP BY，再用 HAVING 过滤分组结果。但注意：HAVING 只能跟在 GROUP BY 后，且只能引用分组字段或聚合表达式。
-
HAVING是对分组后的结果集做筛选，不是对原始行 - 如果没
GROUP BY，HAVING会把整张表当一个组处理（慎用） - 想同时按用户筛选、又按订单聚合？得用子查询或 CTE，不能只靠
HAVING
子查询套在 HAVING 里？多数情况行不通
HAVING 后面不能直接跟子查询（比如 HAVING COUNT(*) > (SELECT avg_cnt FROM stats)），MySQL 5.7+ 和 PostgreSQL 会报错 Subquery in HAVING clause is not supported（具体错误信息因版本而异）。这不是语法疏漏，而是执行顺序导致的限制：聚合计算完成前，子查询可能还没执行或上下文不匹配。
真正能跑通的写法是把子查询提前到 FROM 或 JOIN 阶段，让结果变成可比的列。
- 把子查询作为派生表（
FROM (SELECT ...)）并JOIN到主表 - 用
WITH先算出阈值，再在HAVING中引用该 CTE 的字段（PostgreSQL/MySQL 8.0+ 支持） - 避免在
HAVING内写(SELECT ...)—— 看似简洁，实际多数数据库不认
替代方案：用子查询先过滤，再聚合（更通用）
当逻辑复杂、涉及多层条件（比如“只统计近30天下单且收货地址在上海的用户”），与其硬塞进 HAVING，不如把过滤逻辑前置到子查询里。这样既清晰，又兼容所有主流 SQL 引擎。
示例：查每个用户的订单数，但只统计状态为 'shipped' 且创建时间在近7天内的订单
SELECT user_id, COUNT(*) AS order_count
FROM (
SELECT user_id
FROM orders
WHERE status = 'shipped'
AND created_at >= CURRENT_DATE - INTERVAL '7 days'
) AS filtered_orders
GROUP BY user_id
HAVING COUNT(*) > 3;- 子查询负责“行级过滤”，确保输入聚合的数据是干净的
-
GROUP BY+HAVING负责“分组后筛选”，两者职责分明 - 如果子查询里用了索引字段（如
created_at,status），性能通常比在HAVING里硬扛强得多
容易忽略的 NULL 和空分组问题
用子查询 + GROUP BY 时，如果子查询结果为空（比如没匹配到任何 shipped 订单），整个外层查询会返回零行 —— 这符合预期；但如果子查询返回了 NULL 的 user_id，它会被当成一个独立分组，HAVING 仍可能命中。这点常被忽略，尤其在关联表未加 IS NOT NULL 检查时。
- 检查子查询是否可能输出
NULL值，必要时加WHERE user_id IS NOT NULL -
HAVING COUNT(*) > N对空分组无效，但对含 NULL 的分组有效 —— 行为取决于COUNT(*)（统计所有行）还是COUNT(user_id)（忽略 NULL） - 测试时务必覆盖边界数据：零记录、全 NULL、单一分组等场景
子查询和 HAVING 的联动不是语法拼接游戏，关键在理解执行阶段：过滤在聚合前，比较在聚合后。一旦混淆这个顺序，写的 SQL 要么报错，要么结果不对，还很难 debug。
