报错是因为select中存在既未聚合也未出现在group by子句中的列，违反sql标准语义；数据库无法确定每组应取该列的哪个值，postgresql、mysql 5.7+（only_full_group_by开启时）等均强制校验。
GROUP BY 后为什么报错“column must appear in GROUP BY clause”？
这是 PostgreSQL 和 SQL 标准严格模式下的典型报错，本质是：SELECT 列表里出现了既没被聚合函数包裹、也没出现在 GROUP BY 子句中的列。MySQL 5.7+ 默认开启 sql_mode=ONLY_FULL_GROUP_BY 后也会触发。
- 错误写法：
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id——name未聚合也未分组，数据库无法确定该取哪一行的name - 正确做法：要么把
name加进GROUP BY（前提是user_id和name一一对应），要么用聚合函数包裹，比如MAX(name)或ANY_VALUE(name)（MySQL） - PostgreSQL 中更常见的是用
DISTINCT ON替代模糊聚合，但那是另一条路
WHERE 和 HAVING 的区别到底在哪？
WHERE 过滤行，HAVING 过滤分组——顺序不能错，且 HAVING 只能用在 GROUP BY 之后，里面可以写聚合函数，WHERE 不行。
- 查“订单数超过 5 的用户”：必须用
HAVING COUNT(*) > 5，写在WHERE里会报错 - 查“2024 年的订单中，订单数超 5 的用户”：先
WHERE created_at >= '2024-01-01'过滤原始行，再GROUP BY，最后HAVING COUNT(*) > 5 - 性能上，
WHERE越早过滤掉无关行，GROUP BY处理的数据越少，别把条件全塞到HAVING
GROUP BY 多字段时，结果怎么理解？
多字段 GROUP BY 是按组合值分组，不是分别分组。比如 GROUP BY status, region 会生成所有 (status, region) 唯一组合的分组行。
- 如果某
status在多个region都存在，就会拆成多行；反过来，同一region出现在不同status下也一样 - 注意 NULL 值：SQL 中
NULL = NULL为 false，但GROUP BY把所有 NULL 归为同一组（标准行为） - 想按“地区优先，再按状态”排序结果？加
ORDER BY region, status，它和GROUP BY顺序无关
用 GROUP BY 做去重靠谱吗？
可以，但不推荐当唯一目的用——GROUP BY 是为聚合设计的，SELECT DISTINCT 更语义清晰、可读性高，且多数引擎对 DISTINCT 有专门优化。
- 写
SELECT user_id FROM logs GROUP BY user_id确实能去重，但比SELECT DISTINCT user_id FROM logs多一层分组逻辑开销 - 如果顺带要统计次数，那自然用
GROUP BY user_id+COUNT(*)；纯去重就别硬套 - 某些旧版 SQLite 或嵌入式环境可能不支持
DISTINCT多列，这时才考虑GROUP BY替代，但属于例外场景
真正容易被忽略的是：空字符串 '' 和 NULL 在 GROUP BY 中永远不等价，哪怕业务上认为它们都代表“未填写”。需要统一处理再分组，否则会拆成两组。
