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) < 100;
这在 MySQL 8.0+ 严格模式、PostgreSQL、SQL Server 等所有主流数据库中都会失败，因为 HAVING 没有作用对象：没 GROUP BY，就没有“组”，也就没有聚合结果可筛。
-
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) < 100 AND COUNT(*) <= 2;
-
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 和索引设计。
