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或窗口。漏掉这一步，后面全是调试图。
