HAVING不能直接用于子查询的WHERE中，必须封装为独立子查询或CTE；SQL标准规定HAVING仅适用于顶层SELECT或完整独立查询，否则报“syntax error at or near 'HAVING'”错误。
HAVING 不能直接用于子查询的 WHERE 子句中
你写 WHERE customer_id IN (SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) > 5)，几乎所有主流数据库（PostgreSQL、MySQL 8.0+、SQL Server）都会报错：syntax error at or near "HAVING"。这不是语法打错了，而是 SQL 标准强制规定：HAVING 只能出现在顶层 SELECT 或独立完整查询中，不能嵌在子查询的 WHERE 后面。
必须把 GROUP BY + HAVING 封装成独立子查询或 CTE
聚合结果要“拿出去用”，就得先把它算出来、存住、再引用。不能边算边筛边嵌套。
- 用派生表（带
AS t的子查询）：最通用，兼容 MySQL 5.7 及以上、PostgreSQL、SQL Server - 用
WITHCTE：可读性高，逻辑分层清晰；PostgreSQL 和 SQL Server 对其物化支持更好，执行计划更可控 - 别名在
HAVING里不可用：比如HAVING order_cnt > 5会失败，必须写HAVING COUNT(*) > 5 - MySQL 5.7 不支持 CTE，只能用第一种；若项目需跨版本兼容，优先选派生表写法
LEFT JOIN 场景下 HAVING 会意外丢掉 NULL 行
用 LEFT JOIN users u ON ... LEFT JOIN orders o ON ... GROUP BY u.id HAVING COUNT(o.id) >= 3，所有没订单的用户都会被过滤掉——因为 COUNT(o.id) 对这些用户返回 0，不满足条件。这和“保留所有用户，只对高频用户做聚合”的原始意图冲突。
- 目标是“显示所有用户 + 高频标记”：改用窗口函数，如
COUNT(*) OVER (PARTITION BY u.id)，外层WHERE筛 - 目标是“仅保留高频用户的基本信息”：
HAVING是对的，但得确认业务是否真要丢掉零订单用户 -
COUNT(*)和COUNT(o.id)在LEFT JOIN下行为不同：COUNT(*)把空订单行也计为 1，COUNT(o.id)忽略NULL，务必按语义选
子查询里嵌套聚合比较时，性能容易翻车
如果写 HAVING AVG(amount) > (SELECT AVG(amount) FROM orders)，多数数据库会对每一组重新执行一次子查询——1000 个分组，子查询就跑 1000 次。
- 优先用窗口函数替代，例如
AVG(amount) OVER ()计算全局均值一次，再做比较 - 若必须用子查询，确保它不依赖外层分组（即不相关子查询），否则性能不可控
- CTE 内部提前计算好聚合值，比在
HAVING中反复调用更安全
真正难的不是写出语法正确的语句，而是判断该不该用 HAVING——它天生是“减法操作”，只留满足条件的组。一旦需求变成“保留原始粒度 + 标记聚合特征”，就得立刻转向窗口函数或两层结构。
