GROUP BY多字段分组按列组合值划分组，非聚合列必须全部出现在GROUP BY中；WHERE用于分组前过滤，HAVING用于分组后筛选聚合结果，NULL值会被归为同一组，联合索引可提升性能。
GROUP BY 多字段分组的语法结构
多字段分组就是把数据按两个或以上列的**组合值**划分成组，不是分别分组。比如 GROUP BY department, job_title 表示先按部门分大组，再在每个部门里按职位细分小组——最终每组的 department 和 job_title 值都完全相同。
关键点是：SELECT 中所有非聚合列必须全部出现在 GROUP BY 后面，一个都不能少，也不能顺序错（虽然多数数据库不校验顺序，但写法应保持一致）。
-
SELECT department, job_title, COUNT(*)→ 必须写GROUP BY department, job_title -
SELECT job_title, department, AVG(salary)→GROUP BY job_title, department更清晰，避免混淆 - 漏掉任一非聚合列（如只写
GROUP BY department却 SELECT 了job_title），MySQL 5.7+ 默认报错ERROR 1055，PostgreSQL 和 SQL Server 直接拒绝执行
WHERE 和 HAVING 在多字段分组中的分工
WHERE 是分组前过滤，HAVING 是分组后筛选——这个区别在多字段分组时更容易被忽略，尤其当条件涉及聚合结果时。
- 想查“每个部门/职位组合中，2023年后入职的人数”，用
WHERE hire_date > '2023-01-01'，它先筛人再分组 - 想查“哪些部门/职位组合的平均薪资超过 15000”，必须用
HAVING AVG(salary) > 15000，因为AVG()是分组后才有的值 - 错误写法：
WHERE AVG(salary) > 15000→ 直接报错，AVG()在 WHERE 阶段不可用
常见错误：NULL 值导致分组意外合并或丢失
如果参与分组的字段（如 job_title）含 NULL，不同数据库处理方式不一：MySQL 把所有 NULL 归为同一组；PostgreSQL 也如此；但有些旧版 SQLite 可能行为不一致。
- 现象：
SELECT department, job_title, COUNT(*) FROM employees GROUP BY department, job_title中，所有job_title IS NULL的记录会挤进同一个“空职位”组 - 若想把 NULL 当作独立类别保留（比如统计“职位未填”的人数），无需额外操作；但若想排除它们，加
WHERE job_title IS NOT NULL - 更隐蔽的问题：多个 NULL 字段组合（如
department IS NULL AND job_title IS NULL）仍算作一组，容易掩盖数据质量问题
性能与可读性建议：别滥用多字段分组
字段越多，分组粒度越细，结果行数可能爆炸式增长——比如按 region, city, store_id, product_id 分组，上万行很常见，但未必有业务意义。
- 先确认业务目标：是要看“各城市各门店销量”，还是“各区域总销量”？后者只需
GROUP BY region - 索引能显著加速多字段分组，建议在 GROUP BY 列上建联合索引，顺序尽量匹配分组顺序（如
INDEX(department, job_title)） - 临时表或 CTE 可提升可读性：先
SELECT department, job_title, AVG(salary) AS avg_sal FROM ... GROUP BY department, job_title，再用该结果做进一步过滤或 JOIN
多字段分组本身不难，真正容易出问题的是对分组逻辑的理解偏差——尤其是 WHERE/HAVING 混用、NULL 处理和过度分组带来的性能陷阱。
