mysql严格要求select非聚合字段必须出现在GROUP BY中，否则报错；WHERE过滤分组前数据且不可用聚合函数，HAVING过滤分组后结果且必须用聚合函数或分组字段；多字段GROUP BY顺序影响语义与排序；NULL值会被归为同一组，需注意统计偏差。
GROUP BY 后 select 字段必须合法
MySQL 严格要求：SELECT 列表中出现的**非聚合字段，必须完整出现在 GROUP BY 子句中**。否则会报错：Expression #1 of SELECT list is not in GROUP BY clause（尤其在 SQL mode 开启 ONLY_FULL_GROUP_BY 时，这是 MySQL 5.7+ 默认行为）。
- ✅ 正确写法：
SELECT department, count(*) FROM employees GROUP BY department; - ❌ 错误写法：
SELECT department, name, COUNT(*) FROM employees GROUP BY department;（
name既没在GROUP BY中，也没被聚合函数包裹） - ⚠️ 注意：即使某
department下所有name都相同，MySQL 也不允许“侥幸通过”——它不保证返回哪一行的name，且新版会直接拒绝执行
HAVING 是分组后过滤，WHERE 是分组前过滤
WHERE 在分组前筛行，不能用聚合函数；HAVING 在分组后筛组，必须用聚合函数或分组字段。混淆两者是高频出错点。
- 要查「2023 年下单超过 5 次的用户」？→ 先
WHERE order_time >= '2023-01-01'，再HAVING COUNT(*) > 5 - ❌ 错误：
SELECT user_id, COUNT(*) c FROM orders WHERE COUNT(*) > 5 GROUP BY user_id;（
COUNT(*)在WHERE中非法） - ✅ 正确：
SELECT user_id, COUNT(*) c FROM orders WHERE order_time >= '2023-01-01' GROUP BY user_id HAVING COUNT(*) > 5;
多字段 GROUP BY 的顺序和语义很关键
GROUP BY a, b 不等于 GROUP BY b, a——虽然结果行数可能一样，但分组逻辑和排序倾向不同，尤其配合 ORDER BY 或窗口函数时影响明显。
- 语义上：先按
a分大组，每个大组内再按b拆小分组 - 例如：
SELECT dept, role, AVG(salary) FROM staff GROUP BY dept, role;表示「每个部门里的每个职位的平均薪资」
- 若写成
GROUP BY role, dept，逻辑不变，但 MySQL 在无显式ORDER BY时，返回顺序可能不同（不保证稳定） - ? 实操建议：始终按业务主次顺序写字段，比如「先部门、再岗位」比「先岗位、再部门」更符合管理视角
别忽略 NULL 值的分组行为
MySQL 把所有 NULL 值视为「相等」，归入同一组。这常导致统计偏差——比如你查 COUNT(*) 时发现某组数量异常高，很可能就是一堆 NULL 被悄悄合并了。
- 示例：
SELECT category, COUNT(*) FROM products GROUP BY category;若
category有 10 条为NULL，它们会全挤进同一行，显示为NULL | 10 - 想单独处理空值？可加判断：
SELECT IF(category IS NULL, '未分类', category) AS cat_group, COUNT(*) FROM products GROUP BY cat_group; - ⚠️ 注意：
GROUPING()函数仅在支持WITH ROLLUP的上下文中区分“真 NULL”和“汇总占位符”，普通GROUP BY里无效
真正容易被忽略的是：GROUP BY 不是“取每组第一条”，而是强制要求语义明确——你要么声明分组依据，要么说明如何压缩该列（用聚合函数）。很多看似“能跑通”的旧 SQL，只是因为关了 ONLY_FULL_GROUP_BY，实际结果不可靠。