GROUP BY多字段顺序影响分组逻辑和业务理解，必须与SELECT中非聚合字段一致且按业务主次排列；NULL值会独立成组；COUNT(*)与COUNT(salary)口径不同，需区分总人数和有效工资人数。
GROUP BY 多字段的语法顺序不能乱
多字段分组时，GROUP BY 后字段的书写顺序，直接决定结果集的排序逻辑和嵌套层级感（虽然 SQL 标准不保证默认顺序，但多数引擎如 MySQL、PostgreSQL 会按 GROUP BY 顺序做隐式排序）。更重要的是：它影响你后续加 ORDER BY 或对接前端分组展示时的理解成本。
比如统计「部门 + 职位」维度的平均工资，必须写成：
SELECT dept, position, AVG(salary) AS avg_salary FROM employees GROUP BY dept, position;
而不是 GROUP BY position, dept——后者结果按职位优先排列，部门变成次级维度，容易在报表里造成归类错觉。
- 字段顺序应匹配业务主次：部门是组织单元，职位是角色类型，通常“先部门、后职位”更符合管理视角
- 若漏写某字段（如只写
GROUP BY dept却 SELECTposition），MySQL 5.7+ 严格模式下会报错Expression #2 of SELECT list is not in GROUP BY clause - 所有非聚合字段（
dept、position）都必须出现在GROUP BY中，一个都不能少
NULL 值会让分组“消失”或孤立成一组
如果 dept 或 position 有 NULL，它们会被当作一个独立分组参与聚合。例如 dept = NULL 的员工，不管 position 是什么，都会被挤进同一行：(NULL, 'Engineer') 和 (NULL, 'Manager') 不会合并，但 (NULL, NULL) 会单独成组。
这常导致报表里突然冒出“未知部门-未知职位”一行，平均工资还偏低（因为 NULL 行往往对应试用期/外包等低薪数据）。
- 检查空值分布：
SELECT COUNT(*) FROM employees WHERE dept IS NULL OR position IS NULL; - 想排除空值再统计？加
WHERE dept IS NOT NULL AND position IS NOT NULL - 想把 NULL 显式转义为字符串便于识别？用
COALESCE(dept, '未分配')，但注意：COALESCE后的值也得放进GROUP BY
AVG() 会自动忽略 NULL 工资，但别误判人数
AVG(salary) 确实跳过 salary IS NULL 的记录，这点放心。但很多人会顺手用 COUNT(*) 算“该部门该职位总人数”，这就错了——COUNT(*) 统计的是分组内所有行数，包括 salary 为 NULL 的人；而 AVG() 分母是 salary 非 NULL 的行数。
结果就是：平均工资分母变小，数值虚高；同时 COUNT(*) 显示的人数比实际发薪人数多。
- 要统计真正参与计算的工资条数，用
COUNT(salary)（它只数非 NULL 值） - 想同时看总人数和有效工资人数？写两列：
COUNT(*) AS total_cnt, COUNT(salary) AS salary_cnt - 需要四舍五入？
ROUND(AVG(salary), 2)，避免浮点数末尾一长串小数干扰阅读
聚合结果排序和限制需额外处理
GROUP BY 本身不提供排序能力，也不支持 LIMIT 直接截断分组后结果（MySQL 5.7 允许但属非标行为，8.0+ 已移除）。想取“每个部门薪资最高的职位”，不能靠 GROUP BY dept, position LIMIT 10 解决。
- 简单排序加
ORDER BY dept, avg_salary DESC即可满足多数看数需求 - 真要 Top-N 每组？得用窗口函数：
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY AVG(salary) DESC)，再套一层子查询过滤 - 导出到 Excel 前发现数据量大？先确认是否真需要全量——加
HAVING COUNT(salary) >= 5过滤掉样本太少的组合，避免平均值失真
多维聚合看着简单，但 NULL 处理、计数口径、排序边界这些地方，一不留神就让报表数字对不上人力系统的花名册。动手前先 SELECT dept, position, salary 抽样扫几眼空值和异常值，比调半天 GROUP BY 语句更省时间。
