必须用HAVING而非WHERE过滤分组结果，因为WHERE在分组前执行，无法访问COUNT(*)等聚合结果，否则报错“aggregate functions are not allowed in WHERE”；正确写法是先GROUP BY再HAVING。
用 HAVING 而不是 WHERE 过滤分组结果
分组后判断条件，必须用 HAVING，WHERE 在分组前就执行，无法访问聚合结果。比如想查“订单数 ≥ 5 的用户”，WHERE COUNT(*) >= 5 直接报错：ERROR: aggregate functions are not allowed in WHERE。
正确写法是先 GROUP BY user_id，再用 HAVING COUNT(*) >= 5 筛分组。
-
WHERE过滤行，HAVING过滤组，顺序不可颠倒 -
HAVING中只能出现分组字段或聚合表达式（如AVG(amount)、MAX(created_at)） - MySQL 和 PostgreSQL 行为一致；SQLite 支持但要求所有
SELECT字段都在GROUP BY中或被聚合
多个条件组合时注意逻辑优先级
HAVING 支持 AND/OR，但容易因括号缺失导致误判。例如查“平均订单金额 > 100 且最近下单在 30 天内”的用户，不能写成 HAVING AVG(amount) > 100 AND MAX(created_at) > NOW() - INTERVAL '30 days' —— 如果某组里有新订单但平均金额低，仍会被保留，这未必是你想要的“同时满足”。
- 确认业务语义：是“组内所有行都满足”，还是“组统计值满足”？前者通常需子查询或窗口函数
- 时间类条件（如
MAX(created_at)）反映的是该组最新时间，不是每条记录的时间 - 混合
AND/OR时务必加括号，例如HAVING (COUNT(*) > 3 OR SUM(amount) > 5000) AND AVG(amount) > 200
需要逐行验证时，HAVING 不够用
如果条件涉及“组内是否存在某类记录”，比如“用户既有退款订单又有支付成功订单”，HAVING 无法直接表达。因为 COUNT(CASE WHEN status = 'refunded' THEN 1 END) > 0 只能说明存在退款，但不能保证另一类也存在。
- 典型解法是用布尔聚合：PostgreSQL 用
BOOL_OR(status = 'refunded')和BOOL_OR(status = 'paid')；MySQL 用SUM(status = 'refunded') > 0 - 更清晰的方式是先用
GROUP BY user_id+ARRAY_AGG(status)（PG）或GROUP_CONCAT(status)（MySQL），再用字符串匹配，但性能较差 - 复杂逻辑建议拆到应用层，或用
EXISTS子查询关联原表，避免在聚合后硬凑
性能陷阱：HAVING 不走索引，慎用高基数分组
HAVING 是在内存中对已分组结果过滤，不利用索引。当 GROUP BY 字段区分度极高（如按 order_id 分组），分组本身就很慢，HAVING 还会拖慢最终输出。
- 优先在
WHERE阶段缩小数据集：比如先WHERE created_at >= '2024-01-01'再分组 - 避免在
HAVING中调用函数（如HAVING DATE(created_at) = '2024-01-01'），会导致无法利用created_at索引 - 如果只是要“是否存在满足条件的组”，用
EXISTS (SELECT 1 FROM ... GROUP BY ... HAVING ...)比SELECT ... GROUP BY ... HAVING ...更快
分组条件判断看着简单，但聚合语义、执行顺序和索引行为交织在一起，稍不留意就会返回错数据或拖垮查询。动手前先问一句：这个“条件”到底是在评价整组，还是在检查组内每一行？
