MySQL 8.0.13+ 启用 ONLY_FULL_GROUP_BY 后，SELECT 中非聚合字段必须出现在 GROUP BY 中；HAVING 只能引用 SELECT 或 GROUP BY 中的列或聚合表达式；ORDER BY 需显式指定才能保证分组后顺序；GROUP BY NULL 实现全表聚合。
GROUP BY 后必须出现 SELECT 中的所有非聚合字段
MySQL 8.0.13+ 默认启用 sql_mode=ONLY_FULL_GROUP_BY，这意味着如果 SELECT 列表里有非聚合字段（比如 name、status），它必须出现在 GROUP BY 子句中，否则报错：Expression #1 of SELECT list is not in GROUP BY clause。
常见错误写法：
SELECT id, name, COUNT(*) FROM users GROUP BY status;
这里 id 和 name 既没聚合也没分组，直接报错。解决方式只有三种：
- 把
id和name加进GROUP BY（但通常语义不合理） - 用聚合函数包裹，如
MAX(name)、MIN(id) - 临时关闭
ONLY_FULL_GROUP_BY（不推荐，掩盖逻辑问题）
HAVING 和 WHERE 的区别不能只记“过滤时机”
WHERE 过滤行，HAVING 过滤分组 —— 这句话没错，但容易忽略关键约束：HAVING 只能引用 SELECT 中的列或聚合表达式，不能引用原始表字段（除非该字段也在 SELECT 或 GROUP BY 中）。
例如以下写法会报错：
SELECT status, COUNT(*) FROM users GROUP BY status HAVING created_at > '2023-01-01';
因为 created_at 没出现在 SELECT 或 GROUP BY 中，HAVING 看不到它。正确做法是：
- 改用
WHERE提前过滤：WHERE created_at > '2023-01-01' GROUP BY status - 或把
created_at加入GROUP BY（但通常会导致分组过细） - 或用聚合函数，如
HAVING MAX(created_at) > '2023-01-01'
ORDER BY 在 GROUP BY 后的行为很实际
分组后默认不保证顺序，即使你写了 GROUP BY x，结果集顺序仍可能随 MySQL 版本、索引、执行计划变化。必须显式写 ORDER BY 才能稳定排序。
注意两个细节：
-
ORDER BY可以直接用GROUP BY字段名，也可以用别名（如SELECT status AS s, COUNT(*) c GROUP BY status ORDER BY s） - 如果
SELECT里用了聚合函数，ORDER BY也能直接写函数，比如ORDER BY COUNT(*) DESC，无需别名 - MySQL 允许
ORDER BY引用未出现在SELECT中的字段，只要它在GROUP BY里（但其他数据库如 PostgreSQL 不允许）
GROUP BY NULL 是个冷门但有用的技巧
GROUP BY NULL 会让整张表聚合成一行，常用于快速统计总数或判断是否存在数据：
SELECT COUNT(*), MAX(updated_at), MIN(created_at) FROM logs GROUP BY NULL;
它等价于去掉 GROUP BY，但显式写出更清晰地表达了“全表聚合”意图。注意它和 SELECT COUNT(*) FROM logs 的执行计划通常一致，但如果你还要同时取多个聚合值（比如最大/最小时间），GROUP BY NULL 更直观。
另一个典型场景是配合 IFNULL 做空值兜底：
SELECT IFNULL(AVG(score), 0) AS avg_score FROM exam_results GROUP BY NULL;
避免空表时返回 NULL 行，而是确保总有一行数值结果。
真正难的是理解哪些字段该放进 GROUP BY、哪些该聚合——这取决于业务语义，不是语法能自动推导的。一个字段是否“天然属于分组维度”，得看它是不是每个分组内都唯一或稳定。别依赖 ANY_VALUE() 来绕过检查，那只是把问题往后拖。
