WHERE子句不能直接使用COUNT()或AVG()等聚合函数，因其执行顺序在GROUP BY之前，此时数据尚未分组、聚合值未生成，数据库在语法解析阶段即报错；必须先GROUP BY再用HAVING筛选分组结果。
WHERE 里不能直接用 COUNT() 或 AVG() 做条件筛选
直接写 WHERE COUNT(*) > 5 会报语法错误，因为 WHERE 执行时还没分组、也没算出聚合值。数据库根本不知道“这个 COUNT 是对谁算的”。必须先 GROUP BY，再用 HAVING 过滤分组结果。
常见错误现象：ERROR 1111 (HY000): Invalid use of group function
- 没写
GROUP BY却在WHERE里用聚合函数 → 报错 - 写了
GROUP BY但把本该放HAVING的条件错塞进WHERE→ 条件被提前过滤，结果漏数据 - MySQL 5.7+ 开启
only_full_group_by模式时，SELECT列含非分组非聚合字段 → 报错
多个聚合条件必须合并到一个 HAVING 子句中
HAVING 不支持写多个，也不能拆成 HAVING COUNT(*) > 3 HAVING AVG(amount) > 100 —— 这是语法错误。所有聚合条件得用 AND 或 OR 合并在单个 HAVING 里。
典型场景：查“订单数 ≥ 3 且平均金额 > 100 的客户”
SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) >= 3 AND AVG(amount) > 100;
-
COUNT(*)统计全部行（含amount为NULL的记录）；若只统计有金额的订单，改用COUNT(amount) -
AVG(amount)自动忽略NULL，无需额外处理 - 如果误把
order_date加进GROUP BY，COUNT(*)就变成“每天订单数”，逻辑全偏
想查原始记录而不是分组摘要？用窗口函数代替 GROUP BY + HAVING
上面的 GROUP BY ... HAVING 只返回 customer_id，如果你要导出这些客户的全部订单明细（比如每条订单的金额、时间、商品），就得再套一层——窗口函数是最干净的解法。
SELECT *
FROM (
SELECT *,
COUNT(*) OVER (PARTITION BY customer_id) AS cnt,
AVG(amount) OVER (PARTITION BY customer_id) AS avg_amt
FROM orders
) t
WHERE cnt >= 3 AND avg_amt > 100;- 窗口函数不改变行数，每行都带上了所属客户的聚合值
- 避免了子查询 +
JOIN的嵌套，执行计划更可控 - 注意兼容性：
OVER()在 SQLite 3.25+、PostgreSQL 8.4+、MySQL 8.0+、SQL Server 2005+ 支持；旧版 MySQL 只能用子查询或临时表
多维度交叉统计用 CASE WHEN 嵌套在聚合函数里
报表常需“同一张表里算多个口径”：比如按地区统计总销售额、电子类销售额、已完成订单数。不用跑三条 SQL，一条搞定。
SELECT region, SUM(amount) AS total_sales, SUM(CASE WHEN product_category = 'Electronics' THEN amount ELSE 0 END) AS electronics_sales, COUNT(CASE WHEN status = 'Completed' THEN order_id END) AS completed_orders_count FROM orders GROUP BY region;
-
CASE WHEN ... THEN ... ELSE 0 END保证SUM()不因 NULL 失效 -
COUNT(...)要忽略无效行，就让非匹配项返回NULL（COUNT天然跳过NULL） - 别用
COUNT(CASE ...)配ELSE 0——COUNT(0)会把 0 当有效值计入，结果偏高
真正容易被忽略的是：聚合字段的语义是否和 GROUP BY 键完全对齐。哪怕多加一个看似无关的字段（比如 GROUP BY customer_id, created_at），整个分组粒度就从“客户级”退化成“客户+时间点级”，后续所有聚合值都会失真——这种错误在调试时极难察觉，得从业务目标反推分组逻辑是否合理。
