group by配合count()是标准做法，但常见错误包括：分组字段与select非聚合字段不一致、空值处理不当、where与having混淆、null值分组被忽略；语义上count(*)统计所有行，count(列)仅统计非null值。
直接说结论：用 GROUP BY 配合 COUNT() 是唯一标准做法，但错在写法顺序、空值处理和聚合粒度不匹配上的人，比语法写错的多得多。
GROUP BY 的字段必须和 SELECT 中非聚合字段完全一致
这是最常报错的点——比如你写 SELECT name, COUNT(*) FROM users GROUP BY id，MySQL 8.0+ 会直接报错 Expression #1 of SELECT list is not in GROUP BY clause。因为 name 不是分组键，也没被聚合，数据库不知道该取哪一行的 name。
- 正确写法是：所有非聚合列（如
name）必须出现在GROUP BY中，例如GROUP BY name或GROUP BY name, city - 如果想按
id分组但又想显示name，得确认id和name是一一对应的（否则逻辑本身就有歧义） - PostgreSQL 更严格，SQL 标准也要求如此；MySQL 开启了
ONLY_FULL_GROUP_BY模式后行为就和它们一致
COUNT(*)、COUNT(列名)、COUNT(1) 的区别不是性能，而是语义
很多人以为 COUNT(1) 比 COUNT(*) 快，其实现代数据库基本都做了优化，三者执行计划通常一样。真正关键的是结果含义不同。
-
COUNT(*)统计行数，包括含NULL的行 -
COUNT(col)只统计该列非NULL的行数（比如COUNT(email)会自动跳过邮箱为空的记录） -
COUNT(1)和COUNT(*)行为一致，但可读性差，建议统一用COUNT(*)
WHERE 和 HAVING 混用导致过滤失效
常见错误是把本该在分组后筛选的条件写进 WHERE，比如“查订单数超过 5 的用户”，却写了 WHERE COUNT(*) > 5——这会直接报错，因为 COUNT() 是聚合函数，不能出现在 WHERE 中。
-
WHERE过滤的是“分组前”的原始行（如WHERE status = 'paid'） -
HAVING过滤的是“分组后”的聚合结果（如HAVING COUNT(*) > 5） - 执行顺序是：
FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，记不住就记住：HAVING 紧挨着 GROUP BY，专管聚合结果
分组计数时 NULL 值自成一组，但容易被忽略
如果按 city 分组，而表里有 10 条 city IS NULL 的记录，那结果里会明确出现一行 NULL | 10。这不是 bug，是标准行为，但业务上常被当成“没数据”漏看。
- 想排除空值，加
WHERE city IS NOT NULL - 想把空值归入某类（如“未知”），可用
CASE WHEN city IS NULL THEN 'Unknown' ELSE city END生成新列再分组 - 注意字符串
'NULL'和真正的NULL是两回事，别用= 'NULL'去判断
GROUP BY + COUNT 看似简单，但实际出问题往往不在语法，而在对“分组维度”和“空值语义”的理解偏差。尤其是当关联多表后再分组时，重复行、笛卡尔积、隐式类型转换都会让计数突然变大或变小——这时候光看 COUNT 没用，得先 SELECT * 抽样几条原始数据看清楚再说。
