HAVING必须紧接GROUP BY后，用于筛选分组后的聚合结果；无GROUP BY时使用HAVING会因无分组目标而报错（如MySQL ERROR 1140），且其条件仅允许GROUP BY列或聚合函数。
HAVING 必须紧接 GROUP BY 之后，且只能用于筛选分组后的聚合结果；单独写 HAVING 或把它放在 WHERE 前面，一定会报错。
为什么直接写 HAVING 会报 ERROR 1140 或类似错误
数据库执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT，HAVING 的作用对象是“每组聚合出来的一行”，不是原始数据行。没 GROUP BY，就没有“组”，HAVING 就失去筛选目标。
- 错误写法：
SELECT customer_id, SUM(amount) FROM orders HAVING SUM(amount) > 1000→ MySQL 报ERROR 1140，PostgreSQL 报syntax error at or near "HAVING" - 正确写法必须带
GROUP BY：SELECT customer_id, SUM(amount) FROM orders GROUP BY customer_id HAVING SUM(amount) > 1000 - 极少数旧版 MySQL（5.7 且
SQL_MODE宽松）可能“容忍”无GROUP BY的HAVING，但返回结果不可靠，跨库迁移必崩
HAVING 中能用哪些字段和表达式
HAVING 的条件里，只允许出现两类东西：已出现在 GROUP BY 中的列（或其表达式），以及聚合函数（如 COUNT()、MAX()、AVG()）。
- 合法：
GROUP BY status后写HAVING status = 'active'或HAVING COUNT(*) > 5 - 非法：
GROUP BY status后写HAVING created_at > '2023-01-01'（created_at既没分组也没聚合） - 想用时间字段做判断？得套聚合函数：
HAVING MAX(created_at) >= '2024-01-01' - MySQL 8.0+ 允许在
HAVING中用SELECT别名（如HAVING total > 1000），但 PostgreSQL/SQL Server/SQLite 不支持，兼容写法是重复表达式：HAVING SUM(amount) > 1000
WHERE 和 HAVING 混用时，最容易踩的三个坑
两者分工明确：WHERE 筛行，HAVING 筛组。混用不当轻则性能差，重则逻辑错、结果空。
- 把本该放 WHERE 的条件塞进 HAVING：比如
HAVING order_date > '2023-01-01'（而order_date不在GROUP BY里）→ 直接报错；若强行加进GROUP BY，又导致分组粒度变细，结果失真 - 忽略 NULL 对聚合的影响：某组所有
price都是NULL，MAX(price) > 100返回UNKNOWN，该组被静默丢弃；稳妥写法是HAVING MAX(price) > 100 OR MAX(price) IS NOT NULL - LEFT JOIN + HAVING 导致“假 INNER JOIN”：用
LEFT JOIN orders o ON u.id = o.user_id，再HAVING COUNT(o.id) >= 3，会把所有订单数
子查询或 CTE 里怎么用 HAVING
标准 SQL 不允许在子查询的 WHERE 后直接跟 HAVING。必须把带 GROUP BY + HAVING 的逻辑封装成独立子查询或 CTE。
- 错误写法（PostgreSQL/MySQL 8.0+ 均报错）：
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5) - 正确写法（派生表）：
SELECT * FROM users WHERE id IN (SELECT user_id FROM (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5) AS t) - 更推荐 CTE（尤其逻辑复杂时）：
WITH active_users AS (SELECT user_id FROM orders GROUP BY user_id HAVING COUNT(*) > 5) SELECT * FROM users u JOIN active_users a ON u.id = a.user_id - CTE 内部的
HAVING不能引用外层别名，也不能用外层字段，它只认自己子查询范围内的列和聚合
真正难的不是语法，而是判断“这个条件到底该放 WHERE 还是 HAVING”——关键就看它是否依赖聚合结果。一旦开始数、求最值、算平均，就必须进 HAVING；其余能提前筛的，一律塞 WHERE 里，否则索引失效、扫描膨胀、NULL 失控，问题全来。
