group by报错因非聚合字段未分组或聚合，如select dept, name, count()需将name加入group by或用max(name)等聚合；where在分组前过滤，having在分组后过滤；多字段分组注意null处理、索引顺序及函数导致索引失效；count()统计所有行，count(col)忽略null；取每组最新记录需窗口函数而非group by。
GROUP BY 报错：SELECT 中字段没分组也没聚合
直接报错是常态，不是配置问题。MySQL 5.7+、PostgreSQL、SQL Server 默认拒绝执行 SELECT dept, name, COUNT(*) FROM emp GROUP BY dept 这类语句，错误信息通常是 ERROR 1055 或类似“nonaggregated column”提示。
- 根本原因：数据库不知道你想要哪一行的
name—— 每个部门可能有几十个员工，name取谁的？ - 正确做法：要么把
name加进GROUP BY dept, name（变成按人分组），要么用聚合函数包裹，比如MAX(name)（字典序最大）、STRING_AGG(name, ',')（PostgreSQL）或GROUP_CONCAT(name)（MySQL） - 别信“MySQL 能跑通就没事”：低版本或非严格模式下返回的是某一行的
name，但无法保证是首行、最新行还是随机行，结果不可复现
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越早过滤，GROUP BY处理的数据越少。百万行表上，先WHERE status = 'active'再分组，比全量分组后HAVING筛快得多
多字段分组：NULL、顺序与索引失效风险
GROUP BY region, category 看似简单，但三个细节常被忽略：
-
NULL在分组中是合法值，且所有NULL归为同一组。如果业务上想把region IS 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的行 —— 如果你想知道“注册用户数”，该用后者；想看“总记录数”，必须用前者 -
SUM(sales)遇到整列全NULL返回NULL，不是0。报表里显示空格还是 0，取决于业务需求，补零要显式写COALESCE(SUM(sales), 0) -
AVG(salary)自动跳过NULL值计算，分母是有效值个数。如果某部门 10 人里 3 人工资为NULL，平均值按 7 人算，不是 10 人
真正麻烦的是想取每组“最新一条记录的某个字段”，比如每个部门工资最高的人名。MAX(name) 是字典序最大，MAX(salary) 是数值最大，但两者不来自同一行 —— 这种需求得用窗口函数或子查询，GROUP BY 本身做不到。
