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 温床。
