GROUP BY报错主因是SELECT中含未聚合且未分组的字段；应只选分组字段或聚合结果，慎用HAVING过滤分组后数据，注意NULL参与分组及COUNT语义差异。
GROUP BY 基本写法为什么总报错？
最常见的错误是 SELECT 列表里出现未聚合又没在 GROUP BY 中的字段，比如写 SELECT name, COUNT(*) FROM users GROUP BY status —— 这会报错，因为 name 既没聚合也没分组。MySQL 5.7+ 默认开启 sql_mode=only_full_group_by，严格要求一致性。
- 只选分组字段或聚合函数结果：如
SELECT status, COUNT(*) FROM users GROUP BY status - 想查每个分组的某条记录（比如最新一条），不能靠 GROUP BY 直接“挑”，得用子查询或窗口函数
- 字符串拼接类需求（如合并所有标签）要用
GROUP_CONCAT()，不是直接写SELECT tags
COUNT(*)、COUNT(1)、COUNT(列名) 有啥区别？
三者性能在大多数引擎（如 InnoDB）下几乎一样，但语义不同，误用会导致统计偏差。
-
COUNT(*)统计行数，包括 NULL 行 —— 最安全，推荐作为默认选择 -
COUNT(1)和COUNT(*)在执行计划里通常等价，但可读性差，没必要用 -
COUNT(列名)只统计该列非 NULL 的行数，比如COUNT(email)会漏掉 email 为 NULL 的用户
WHERE 和 HAVING 混用时，顺序和作用对象容易搞反
WHERE 过滤原始行，HAVING 过滤分组后的结果。把条件放错位置，结果就完全不对。
- 要筛“订单金额大于 100 的用户”，用
WHERE amount > 100（单行判断） - 要筛“平均订单金额大于 100 的用户”，必须用
HAVING AVG(amount) > 100（分组后判断） -
HAVING里不能用未聚合的列，比如HAVING name = 'Alice'会报错，除非name是 GROUP BY 字段
多字段分组和 NULL 值处理的实际坑
按多个字段分组很常见，但 NULL 在分组中会被当作一个独立值处理，有时不符合业务预期。
- 写
GROUP BY category, tag时，(NULL, 'hot')和('news', NULL)是两个不同分组 - 如果想把 NULL 当作“未知”统一归并，得提前用
COALESCE(tag, 'unknown')转换 - 分组字段越多，结果集可能越稀疏；加
ORDER BY COUNT(*) DESC能快速定位高频组合
GROUP BY 看似简单，真正卡住人的地方往往不是语法，而是对“分组后数据形态”的误判——比如以为能顺手取某个字段的值，或者没意识到 NULL 也参与分组。写完先看一眼返回的字段是否都合理，比调半天逻辑更省时间。
