having必须配合group by使用，否则报错；因having作用于分组后结果，数据库需先明确分组依据才能筛选聚合条件，单独使用having会导致“mixing of group columns”等错误。
必须先 GROUP BY，否则 HAVING 会报错或行为异常——这是最常踩的坑。
为什么直接写 HAVING 就报错？
错误现象：SQLSTATE[HY000]: General error: 1140 Mixing of GROUP columns with no GROUP columns is illegal 或 MySQL 8.0+ 提示 In aggregated query without GROUP BY。
根本原因：HAVING 不是“通用后置过滤器”，它只在分组上下文中才有意义。数据库需要明确知道“按什么分组”，才能判断“哪一组满足条件”。
常见误操作：
- 写了
HAVING COUNT(*) > 5却漏掉GROUP BY user_id - 想筛全表聚合结果（比如“总订单数是否超 100”），却错误地加了
GROUP BY—— 此时应直接用SELECT COUNT(*) HAVING COUNT(*) > 100（无GROUP BY的全局聚合是合法的，但极少用）
HAVING 中能用哪些字段和表达式？
HAVING 只能引用两类东西：一是 GROUP BY 列本身，二是聚合表达式。不能引用原始行中的非分组、非聚合字段。
例如这张用户订单表关联查询：
SELECT u.id, u.name, COUNT(o.id) AS order_cnt FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name HAVING COUNT(o.id) >= 3;
这里 COUNT(o.id) 是聚合表达式，u.id 和 u.name 在 GROUP BY 中声明过，所以合法。
这些写法会出错：
-
HAVING o.status = 'shipped'——o.status未聚合、也未出现在GROUP BY中 -
HAVING order_cnt > 5—— 别名order_cnt在 MySQL 5.7 默认不可用；MySQL 8.0+ 虽支持，但跨版本兼容性差，建议始终写原表达式COUNT(o.id) > 5 -
HAVING AVG(price) > 100 AND category = 'electronics'—— 如果category没出现在GROUP BY中，就会触发only_full_group_by错误
WHERE 和 HAVING 混用时，顺序和分工怎么定？
执行顺序固定为：WHERE → GROUP BY → HAVING。这个顺序直接影响结果和性能。
典型场景：查“2023 年之后下单、且平均订单金额 ≥ 200 的客户”。
✅ 正确写法（推荐）：
SELECT customer_id, AVG(amount) AS avg_amt FROM orders WHERE order_date > '2023-01-01' GROUP BY customer_id HAVING AVG(amount) >= 200;
⚠️ 错误写法：
-
WHERE AVG(amount) >= 200—— 报错，WHERE不允许聚合函数 -
HAVING order_date > '2023-01-01'—— 报错，order_date未分组也未聚合 - 把日期条件挪到
HAVING里再加MAX(order_date)—— 逻辑错：你不是要“某客户最新订单在 2023 年后”，而是要“该客户所有符合条件的订单都来自 2023 年后”，这只能靠WHERE预过滤
性能提示：能用 WHERE 过滤的，绝不要拖到 HAVING。比如先用 WHERE status = 'paid' 排掉无效订单，再分组，比让每组都算一遍再筛快得多。
NULL 和空组处理容易被忽略
聚合结果为 NULL 时，HAVING 条件默认判为 UNKNOWN，整组会被丢弃——即使你只是想筛“有数据的组”。
比如查“每个品类的平均售价”，但某些品类所有商品 price 都是 NULL：
-
HAVING AVG(price) > 100—— 该品类组直接消失，不报错也不提示 -
HAVING AVG(price) IS NOT NULL AND AVG(price) > 100—— 显式排除NULL组，语义清晰 - 想保留空组（如显示
category = 'toys'但avg_price = NULL），HAVING无能为力，得用条件聚合 +WHERE或子查询
跨数据库迁移时尤其要注意：MySQL 和 PostgreSQL 对 NULL 在比较中的处理一致，但若启用 transform_null_equals = on 等扩展，行为可能突变。稳妥起见，所有涉及聚合值的 HAVING 条件，都应显式检查 IS NOT NULL。
