group by报错源于非聚合字段未明确取值逻辑，需用聚合函数或添加到group by；where在分组前过滤，having在分组后筛选；多字段分组需注意null处理、索引顺序及函数导致索引失效；count(*)统计所有行，count(col)仅统计非null值。
直接报错，不是你写得不对，是数据库在拒绝执行不明确的语义——比如 SELECT dept, name, COUNT(*) FROM emp GROUP BY dept 这种写法，在 MySQL 5.7+、PostgreSQL、SQL Server 上默认就会失败。
GROUP BY 报错：非聚合字段没分组也没包裹
错误信息通常是 ERROR 1055（MySQL）或类似 “nonaggregated column” 的提示。核心问题就一个：数据库不知道你要哪一行的 name —— 每个部门可能有几十个员工，name 取谁的？
- 要么把
name加进GROUP BY dept, name（变成按人分组，失去部门维度） - 要么用聚合函数包裹：
MAX(name)（字典序最大）、MIN(name)（最小）、GROUP_CONCAT(name)（MySQL）、STRING_AGG(name, ',')（PostgreSQL） - MySQL 可临时用
ANY_VALUE(name)，但结果不可控，别在线上依赖 - PostgreSQL 不支持
ANY_VALUE，必须显式处理，否则只能改用子查询或窗口函数
WHERE 和 HAVING 别混用：过滤时机决定对错
WHERE 是在分组前筛原始行，HAVING 是在分组后筛结果组。写反了不是慢一点，是逻辑错误甚至直接报错。
-
WHERE COUNT(*) > 5必报错：Invalid use of group function，因为分组还没开始，COUNT(*)根本不存在 - 想查“2023 年后入职且平均薪资超 15k 的部门”，必须：
WHERE hire_date > '2023-01-01'先缩小数据集，再HAVING AVG(salary) > 15000筛组 - 百万级表上，
WHERE status = 'active'越早加，GROUP BY处理的数据越少，性能差异可能是秒级 vs 分钟级
多字段分组：NULL、顺序、索引失效这三点最易漏
GROUP BY region, category 看似简单，但三个细节常让结果不准或变慢：
-
NULL在分组中是合法值，且所有NULL归为同一组；业务上想当 “unknown”，得提前写COALESCE(region, 'unknown') - 分组字段顺序不影响结果逻辑，但影响索引命中：已有索引
INDEX (category, region)，而你写GROUP BY region, category，该索引大概率失效 - 别在分组字段上套函数：
GROUP BY YEAR(created_at)或GROUP BY UPPER(email)会让索引彻底失效，强制全表扫描；真要按年统计，建生成列created_year INT AS (YEAR(created_at)) STORED并加索引
COUNT(*)、COUNT(col)、SUM(col) 语义差一毫，结果偏千里
统计口径错了很难察觉，但影响真实业务判断：
-
COUNT(*)统计所有行（含整行 NULL），推荐作为默认选择 -
COUNT(email)只统计email IS NOT NULL的行；想统计“填了手机号的用户数”，就不能用COUNT(*) -
COUNT(1)和COUNT(*)在 InnoDB 等主流引擎下执行计划几乎一致，纯属可读性更差的写法，没必要用 - 空组（如某部门没人）不会出现在
GROUP BY结果里，需要补全时得靠LEFT JOIN+ 维度表，不是加个COALESCE就能解决
真正难的不是语法，而是每次写 GROUP BY 前，得想清楚：这个字段在业务上是否和分组键一一对应？如果不确定，就别让它裸露在 SELECT 列表里——宁可用 MIN() 或 MAX() 显式声明取值逻辑，也别赌数据库返回的是“第一行”。
