HAVING中不能写原始字段是因为其执行在GROUP BY之后，此时未分组字段已不可见；正确做法是用WHERE先过滤再分组，HAVING仅用于筛选聚合结果。
WHERE 和 HAVING 混用时，为什么 HAVING 里不能写原始字段？
因为 HAVING 发生在分组（GROUP BY）之后，此时非分组字段已“消失”，只保留聚合结果和分组键。你写 HAVING status = 'active' 会报错——status 不在 GROUP BY 列表里，也没被聚合，数据库压根不认它。
常见错误现象：ERROR: column "status" must appear in the GROUP BY clause or be used in an aggregate function
- 想排除某类数据再分组求和？先用
WHERE过滤，再GROUP BY，最后用HAVING筛聚合结果 - 想“排除某条件后的分组和”，本质是“先剔除、再聚合”，不是“先聚合、再按原始值筛”
-
HAVING只能用：分组字段、聚合函数（如SUM()、COUNT()）、常量或表达式
如何正确实现“排除特定条件后分组求和”？
核心逻辑是：过滤动作必须前置。比如要算“除已取消订单外，各城市的销售总额”，就得先把 status = 'cancelled' 的行干掉，再按城市分组加总。
实操建议：
- 用
WHERE status != 'cancelled'或WHERE status NOT IN ('cancelled', 'failed')先筛数据 - 再
GROUP BY city，然后SUM(amount) - 如果还要进一步限制分组结果（比如只看总和超 10000 的城市），才轮到
HAVING SUM(amount) > 10000
示例：
SELECT city, SUM(amount) AS total
FROM orders
WHERE status NOT IN ('cancelled', 'refunded')
GROUP BY city
HAVING SUM(amount) > 5000;
HAVING 能否替代 WHERE 做条件排除？
不能，也不该。语义和执行顺序都不同：WHERE 是逐行过滤，HAVING 是对分组结果过滤。强行用 HAVING 模拟排除，要么报错，要么逻辑错。
典型翻车场景：
- 写
HAVING status != 'cancelled'→ 报错，status不在分组列中 - 误以为加个
MAX(status)就能绕过 → 实际上MAX(status)可能是 'shipped'，但组里混着 'cancelled'，你根本没真正剔除它 - 性能上更差：先全量分组，再筛组，比先筛再分组多做大量无用聚合
复杂排除条件（如关联表状态、时间窗口）怎么写？
原则不变：把“排除逻辑”尽可能推到 WHERE 子句，哪怕要 JOIN。别指望 HAVING 处理跨表或计算型条件。
例如：排除“用户所在城市为禁售区”的订单
- 正确做法：JOIN
users和cities_blacklist，在WHERE里写cities_blacklist.city IS NULL - 错误做法：试图在
HAVING里写子查询或关联判断——语法不支持，且无法下推过滤 - 注意 LEFT JOIN + IS NULL 的写法比 NOT EXISTS 更易读，也更容易被优化器识别为早期过滤
小提醒：如果排除条件涉及聚合计算（比如“排除平均评分低于3的店铺”），那确实得用子查询或 CTE 预先算出要排除的 ID，再用 WHERE id NOT IN (…) ——这仍是 WHERE 层的事。
