having 必须配合 group by 使用，否则报 error 1140；错误写法是忽略 where 预过滤而直接在 having 中处理全量数据，正确做法是先用 where 筛选（如 order_date），再 group by，最后 having 判断聚合结果，索引应建在 where 和 group by 字段上。

HAVING 本身不能直接“快速”过滤低价值客户——它必须配合 GROUP BY 才能工作，漏掉 GROUP BY 就会报 ERROR 1140。

为什么直接写 HAVING 会报错？

常见错误是想“先算总金额，再筛低于 100 的”，于是写出：

SELECT customer_id, SUM(amount) FROM orders HAVING SUM(amount) 
<p>这在 MySQL 8.0+ 严格模式、PostgreSQL、SQL Server 等所有主流数据库中都会失败，因为 <code>HAVING</code> 没有作用对象：没 <code>GROUP BY</code>，就没有“组”，也就没有聚合结果可筛。</p>

• HAVING 的输入是分组后的一行（比如每个 customer_id 对应一行聚合值），不是原始订单表
• 省略 GROUP BY 后，SUM(amount) 变成全表单值，SQL 标准不允许对单行结果用 HAVING 过滤
• 正确起点永远是：GROUP BY customer_id

筛选低价值客户的标准写法

假设“低价值”定义为：近一年总消费 WHERE，聚合条件放 HAVING：

SELECT customer_id, COUNT(*) AS order_count, SUM(amount) AS total_spent
FROM orders 
WHERE order_date >= '2025-10-01'
GROUP BY customer_id
HAVING SUM(amount) 

• WHERE order_date >= '2025-10-01' 提前减少扫描行数，避免对历史无效数据分组
• HAVING 中的 SUM(amount) 和 COUNT(*) 是每组计算后的结果，合法且高效
• 别名 total_spent 在 HAVING 中可用（MySQL 8.0+），但 PostgreSQL 不支持，跨库建议直接重复表达式

容易踩的坑：NULL 和 COUNT 的陷阱

如果订单表里 amount 字段允许为 NULL，SUM(amount) 会自动忽略这些行，但 COUNT(*) 仍会计数——这可能导致误判“低价值”。更危险的是：

HAVING COUNT(amount) = 0

本意是找“所有订单金额都为 NULL 的客户”，但实际效果是：只要该客户有任何一条 amount IS NOT NULL 的记录，COUNT(amount) 就 ≥ 1，条件永远不成立。

• 想确认“无有效金额”，应该用 COUNT(*) = COUNT(amount)（即非空数量等于总数量）
• 或者更直白：SUM(CASE WHEN amount IS NULL THEN 1 ELSE 0 END) = COUNT(*)
• HAVING 对 NULL 敏感，聚合函数的行为必须和业务定义对齐

性能关键：WHERE 要比 HAVING 早用

低价值客户通常占多数，但你真正关心的可能是“活跃客户里的低价值者”。这时 WHERE 预过滤就至关重要：

• 错误：把 order_date > '2025-01-01' 放 HAVING —— 分组时已处理全量历史数据，浪费 CPU 和内存
• 正确：用 WHERE 切出最近数据，再分组，HAVING 只在小结果集上跑聚合判断
• 索引要建在 WHERE 列（如 order_date）和 GROUP BY 列（如 customer_id）上，HAVING 本身无法走索引

真正卡住查询速度的，往往不是 HAVING 条件本身，而是它前面没做好的 WHERE 和索引设计。