GROUP BY 是使用 COUNT/SUM/AVG 等聚合函数的前提，否则 MySQL 将整表视为单组返回汇总结果；严格模式下 SELECT 非分组非聚合字段会报错；HAVING 用于过滤分组后结果，WHERE 用于分组前筛选；COUNT(*) 统计所有行，COUNT(col) 忽略 NULL；窗口函数可实现明细+汇总并存。
GROUP BY 后才能用 COUNT/SUM/AVG 这类聚合函数
直接在 SELECT 里写 COUNT(*) 却没加 GROUP BY，MySQL 会返回整张表的汇总结果（单行），这不是“对集合分别聚合”，而是把全表当一个组。真要按类别分组统计，GROUP BY 是硬性前提。
常见错误现象：SELECT name, COUNT(*) FROM user; 会报错（SQL mode 严格时）或返回不可靠结果（name 值随机取一行，count 却是总数）。
-
GROUP BY的字段必须出现在SELECT列表中（除非用函数包裹，如MAX(name)） - 想按多个维度分组？写成
GROUP BY dept_id, status，不是嵌套或逗号拼字符串 - MySQL 5.7+ 默认开启
ONLY_FULL_GROUP_BY，禁止“非函数化非分组字段出现在 SELECT 中”——这是保护逻辑，别急着关它
HAVING 用来过滤分组后的结果，不是 WHERE
WHERE 在分组前筛选原始行，HAVING 才能引用 COUNT(*)、SUM(amount) 这类聚合结果。写反了就查不到想要的数据。
例如：查订单数超过 5 的用户，必须用 HAVING COUNT(*) > 5；如果写成 WHERE COUNT(*) > 5，直接语法错误。
-
WHERE可用索引加速，HAVING是在内存中遍历分组结果，大数据量时注意性能 -
HAVING条件里不能用列别名（如AS total），得重复写表达式：HAVING SUM(price) > 1000 - 如果既要前置过滤又要后置聚合过滤，两个都用：
WHERE status = 'paid' GROUP BY user_id HAVING COUNT(*) >= 3
NULL 值在 COUNT/SUM/AVG 中的处理逻辑不同
聚合函数对 NULL 不是统一忽略：
COUNT(*) 统计所有行（含 NULL 字段）；
COUNT(col) 只统计 col IS NOT NULL 的行；
SUM(col) 和 AVG(col) 自动跳过 NULL 值，但若整组都是 NULL，SUM 返回 NULL，AVG 也返回 NULL（不是 0）。
SELECT COUNT(*), -- 行数，不管字段是否为 NULL COUNT(score), -- score 不为 NULL 的行数 SUM(score), -- 忽略 score 为 NULL 的行 AVG(score) -- 同上，且若无非 NULL 值则结果为 NULL FROM exam_result;
- 别假设
AVG会自动补 0，需要补零得用COALESCE(AVG(score), 0) - 用
COUNT(*)判空比COUNT(id)更可靠，尤其当id允许为NULL时
窗口函数替代部分 GROUP BY 场景更灵活
如果既要保留原始行，又想算每组的汇总值（比如“每个订单显示其用户的订单总数”），硬套 GROUP BY 会丢行。这时该用窗口函数：COUNT(*) OVER (PARTITION BY user_id)。
它不折叠数据，而是在每行上附加计算结果，适合明细+汇总并存的报表场景。
- MySQL 8.0+ 支持窗口函数，5.7 及以前只能用关联子查询或临时表模拟，性能差很多
-
PARTITION BY类似GROUP BY分组，但不改变结果集行数 - 慎用
ORDER BY在窗口定义里（如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW），可能触发文件排序，影响性能
聚合逻辑真正卡住人的地方，往往不在语法，而在没想清楚“我要的是按什么粒度汇总”——是每个用户？每天？每个商品类目？先画出分组键，再选函数，最后决定要不要 HAVING 或窗口。漏掉这一步，后面全是调试图。
