GROUP BY后字段必须出现在SELECT或聚合函数中，否则MySQL 5.7+和严格模式PostgreSQL报错；HAVING用于分组后过滤，WHERE用于分组前过滤；多字段分组顺序影响索引与NULL处理；COUNT(*)统计所有行，COUNT(col)仅统计非NULL值。

GROUP BY 后字段必须出现在 SELECT 或聚合函数里

MySQL 5.7+ 和严格模式下的 PostgreSQL 会直接报错，比如写 SELECT name, COUNT(*) FROM users GROUP BY age —— name 既没参与分组，也没被聚合，数据库不知道该取哪一行的 name。这不是语法疏忽，是语义冲突：分组后每组对应多行，name 值可能不唯一。

• 正确做法：只选分组键（age）或套聚合函数（MAX(name)、GROUP_CONCAT(name)）
• MySQL 旧版本默认允许“隐式 ANY_VALUE”，但结果不可靠，别依赖
• PostgreSQL 完全不允许，报错信息通常是：column "xxx" must appear in the GROUP BY clause or be used in an aggregate function

HAVING 是过滤分组结果，不是 WHERE 的替代品

HAVING 和 WHERE 看似都能“筛数据”，但执行时机和作用对象完全不同：WHERE 在分组前过滤原始行，HAVING 在分组后过滤聚合结果。拿错地方，要么查不到想要的组，要么直接报错。

• 想查“订单数超 10 的用户”？用 HAVING COUNT(*) > 10，不能写成 WHERE COUNT(*) > 10（COUNT 在 WHERE 阶段还没计算）
• 想查“2023 年后的订单再分组”？时间条件得放 WHERE order_time > '2023-01-01'，放 HAVING 会先分组再过滤，性能差且逻辑错
• HAVING 支持的表达式受限：只能用分组字段、聚合函数、常量，不能用未聚合的普通列

GROUP BY 多字段时顺序和 NULL 处理要留心

写 GROUP BY a, b 不等于 GROUP BY b, a——虽然结果行数通常一样，但排序行为、索引利用、以及遇到 NULL 时的分组逻辑可能不同。尤其当字段含 NULL，多数数据库把所有 NULL 归为同一组，但这是按值比较的后果，不是特殊规则。

• 复合分组建议按选择性（cardinality）从高到低排，利于优化器用索引，比如 GROUP BY user_id, status 比反过来更稳
• NULL 参与分组时，GROUP BY col 会把所有 NULL 行归一组；若想区分“显式 NULL”和“空字符串”，得提前用 CASE WHEN col IS NULL THEN 'NULL_VAL' ELSE col END
• SQLite 默认允许 SELECT * 配合 GROUP BY，但返回的非分组列值是任意一行的，别当成确定行为

COUNT(*)、COUNT(col)、COUNT(1) 到底有什么区别

它们看起来都数“行数”，但语义和执行细节差得挺远。COUNT(*) 统计的是分组内所有行（包括 NULL），COUNT(col) 只统计该列非 NULL 的行数，COUNT(1) 和 COUNT(*) 在绝大多数引擎里等价，但写法容易误导人以为在“数常量”。

• 要统计“有手机号的用户数”，必须用 COUNT(phone)，不是 COUNT(*)
• 某些老版本 MySQL 对 COUNT(*) 会走索引统计（如 InnoDB 的聚簇索引行数缓存），而 COUNT(col) 必须扫描实际值判断是否为 NULL
• COUNT(1) 没额外价值，还让同事多花半秒想“这 1 是啥意思”，不如统一用 COUNT(*)

GROUP BY 的坑不在语法难记，而在它强制你直面数据的结构本质：哪些值天然可归类，哪些聚合结果才有意义，哪些 NULL 是缺失、哪些是业务状态。一不留神，GROUP BY 就成了隐藏最深的逻辑 bug 温床。