group by字段必须与select非聚合列完全一致，否则报错；count(*)、count(列)、count(distinct 列)语义不同；条件计数用count(case when...then 1 end)；having用于分组后过滤，where不能用聚合函数。
GROUP BY 字段必须和 SELECT 非聚合列完全一致
这是最常触发报错的点，尤其在 MySQL 8.0+ 或 PostgreSQL 中。比如写 SELECT name, COUNT(*) FROM users GROUP BY id，数据库会直接报 Expression #1 of SELECT list is not in GROUP BY clause。
原因不是语法错，而是语义模糊：一个 id 对应多个 name 时，name 到底该取哪一行？
- 正确做法是把
name加进GROUP BY，即GROUP BY id, name - 如果确认
id和name是一一映射（如主键+唯一非空字段），可用ANY_VALUE(name)（MySQL）或MIN(name)（通用）兜底 - PostgreSQL 不支持
ANY_VALUE，必须显式处理，否则只能改用子查询
COUNT(*)、COUNT(列名)、COUNT(DISTINCT 列名) 的语义差异
三者性能几乎没差别，但结果含义完全不同，选错就统计失真。
-
COUNT(*)统计所有行，包括整行都是NULL的记录 -
COUNT(email)只统计email IS NOT NULL的行，email = ''或email = ' '都会被计入（只要不是NULL） -
COUNT(DISTINCT user_id)会跳过user_id IS NULL的行，且自动去重；多字段组合去重得靠CONCAT，例如COUNT(DISTINCT CONCAT(user_id, ',', goods))
常见踩坑：想查“填了手机号的用户数”，却写了 COUNT(*) 而不是 COUNT(phone)，结果把空号用户也算了进去。
条件计数必须用 COUNT(CASE WHEN ... THEN 1 END)
不能靠 WHERE 做分组内筛选，否则会丢失其他维度的计数。比如要同时统计手机订单数和电脑订单数，写两个 WHERE 子查询效率低、难维护。
- 标准写法：
COUNT(CASE WHEN goods = '手机' THEN 1 END)—— 不满足条件返回NULL，COUNT自动忽略 - MySQL 可简写为
COUNT(IF(goods = '手机', 1, NULL)) - 多条件组合直接叠加：例如
COUNT(CASE WHEN price > 1000 AND status = 1 THEN 1 END) - 反向统计（如统计
user_id IS NULL的行）：用COUNT(CASE WHEN user_id IS NULL THEN 1 END)，注意''空字符串不会被匹配
HAVING 必须紧跟 GROUP BY，且只能过滤聚合结果
WHERE 是分组前筛行，HAVING 是分组后筛组。把聚合函数塞进 WHERE 里，100% 报错。
- 错误示例：
WHERE COUNT(*) > 5→ 直接语法错误 - 正确写法：
HAVING COUNT(*) > 5，且必须出现在GROUP BY之后、ORDER BY之前 - 执行顺序固定：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY
- 空组默认不出现：如果某部门没人，
GROUP BY dept结果里根本不会有那行，需用LEFT JOIN补全，不能指望HAVING拉回来
真正容易被忽略的是：GROUP BY 不会自动补全缺失分组，也不做空值对齐 —— 它只忠实返回有数据的组。需要完整维度报表时，必须提前构造维度表再关联。
