having必须配合group by使用，作用于分组后的聚合结果而非原始行；缺失group by时数据库报错或仅视为单组，无法实现按维度筛选。
HAVING 不能脱离 GROUP BY 独立筛选原始行
HAVING 的作用对象不是单条记录，而是“分组后的聚合结果”。如果你写 HAVING COUNT(*) > 3 却没写 GROUP BY，数据库会报错（如 MySQL 8.0+ 的 ERROR 1140）或返回空结果——因为没有分组，就没有“组”可筛。
常见错误现象：
- 执行
SELECT user_id, COUNT(*) FROM orders HAVING COUNT(*) > 5;→ 报错或只返回一行（隐式单组），但你本意是查“订单数超 5 的用户” - 误把
HAVING当成WHERE的增强版，直接加在JOIN后面，结果逻辑全乱
正确理解：HAVING 是分组流水线的下游环节，它依赖 GROUP BY 输出的“组”作为输入。没有 GROUP BY，就只有“一个默认大组”，无法实现按用户、部门等维度的条件过滤。
GROUP BY 缺失时 HAVING 的行为很危险
虽然 SQL 标准允许无 GROUP BY 时用 HAVING（例如 SELECT COUNT(*) FROM t HAVING COUNT(*) > 100），但这仅适用于全局聚合判断，不是业务中常见的“每个用户筛选”场景。
容易踩的坑：
-
LEFT JOIN后直接HAVING COUNT(o.id) >= 3而不GROUP BY u.id→ 实际只算整张连接结果的总订单数，不是每个用户的 - 字段引用出错：
HAVING里用了未出现在GROUP BY中的非聚合列（如HAVING u.name = 'Alice'），多数数据库直接拒绝 - 空值陷阱：
COUNT(o.id)忽略 NULL，COUNT(*)计入 NULL 行，选错会导致过滤条件失效
替代方案比硬套 HAVING + GROUP BY 更灵活
不是所有“聚合后筛选”都必须走 GROUP BY + HAVING。尤其当你要保留明细行、或筛选逻辑复杂时，其他写法更安全、更易读。
可用方案：
- 子查询：先
GROUP BY出满足条件的user_id，再JOIN原表取详情 - 窗口函数：
COUNT(*) OVER (PARTITION BY user_id)算出每用户的订单数，再用外层WHERE过滤 —— 不破坏原始行结构 -
WHERE预过滤：能提前用WHERE卡掉的条件（如状态 = 'paid'），别留到HAVING阶段，减少分组数据量
性能影响明显：无谓的 GROUP BY 会强制全表分组，而窗口函数或子查询可能走索引 + limit，快得多。
GROUP BY 列必须包含所有非聚合字段
这是语法硬约束，不是风格建议。比如写 SELECT u.id, u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ... GROUP BY u.id，漏了 u.name → 多数数据库（PostgreSQL、SQL Server、MySQL 5.7+ 严格模式）直接报错。
原因很简单：一个 u.id 可能对应多个 u.name（数据异常或设计问题），数据库无法确定该选哪个值。所以要么补全 GROUP BY u.id, u.name，要么用 MAX(u.name) 这类聚合包裹。
容易忽略的点：
- ORDER BY 中的字段也受同样规则限制，不能出现未聚合也未分组的列
- 使用
ANY_VALUE()（MySQL）或FIRST_VALUE()是绕过手段，但语义模糊，慎用
真正难的从来不是写对 HAVING，而是想清楚：你到底要筛“组”，还是筛“行”，以及这个“组”的边界由哪些字段定义。漏掉一个分组键，结果就不可靠。
