MySQL 5.7+和PostgreSQL严格模式下GROUP BY报“Expression not in GROUP BY clause”错误，是因非分组字段未被聚合函数包裹或未出现在GROUP BY中，需用MAX(b)、ANY_VALUE(b)或STRING_AGG(b,',')等修正。
GROUP BY报错“Expression not in GROUP BY clause”怎么办
MySQL 5.7+ 和严格模式下的 PostgreSQL 会拒绝执行 SELECT a, b, COUNT(*) FROM t GROUP BY a 这类语句，因为 b 既没在 GROUP BY 中，也没被聚合函数包裹。这不是 bug，是 SQL 标准强制要求：非分组字段必须明确其聚合含义。
常见错误现象：ERROR 1055 (42000): Expression #2 of SELECT list is not in GROUP BY clause
- 检查
sql_mode：运行SELECT @@sql_mode，若含ONLY_FULL_GROUP_BY，说明启用了严格校验 - 临时绕过（不推荐）：执行
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''))—— 仅用于调试，上线前必须修复逻辑 - 正确做法：把所有非分组字段都套上聚合函数，比如
MAX(b)、ANY_VALUE(b)（MySQL）、STRING_AGG(b, ',')（PostgreSQL）
GROUP BY结果行数比预期少：是不是隐式去重了
GROUP BY 本身不会“丢数据”，但如果你的分组字段存在 NULL 值或类型隐式转换，就可能让本该分开的行被合并。
典型场景：用字符串字段分组，但该字段有前后空格、大小写混用、或存储了 '0' 和 0（数字 vs 字符串）
- 先查原始数据分布：
SELECT col, COUNT(*) FROM t GROUP BY col ORDER BY COUNT(*) DESC LIMIT 5，再对比SELECT TRIM(UPPER(col)), COUNT(*) ...看是否数量突变 - 注意 MySQL 中
GROUP BY对NULL的处理：所有NULL被视为同一组，而WHERE col IS NULL可能漏掉这部分 - 避免依赖隐式转换：显式 cast，例如
GROUP BY CAST(user_id AS CHAR)，尤其当字段是INT但业务上要按字符串语义分组时
聚合结果值不对：COUNT(*)、COUNT(col)、COUNT(1) 区别在哪
不是所有 COUNT 都等价。误用会导致统计口径偏差，比如想算“有效订单数”，却写了 COUNT(*) 把已取消的也算了进去。
-
COUNT(*)：统计行数（包括含NULL的行） -
COUNT(col)：只统计col IS NOT NULL的行数 -
COUNT(1)：和COUNT(*)行为一致，性能无差别，别信“更快”的说法 - 容易踩的坑：
SUM(CASE WHEN status='paid' THEN 1 ELSE 0 END)和COUNT(CASE WHEN status='paid' THEN 1 END)结果不同——后者会忽略ELSE分支，等价于只计非NULL的THEN结果
JOIN后GROUP BY结果膨胀：是不是笛卡尔积搞的鬼
多表 JOIN 后直接 GROUP BY，如果关联关系是一对多，聚合前就已产生重复行，导致 SUM()、COUNT() 失真。
例如：订单表 orders 关联订单项表 order_items，一个订单有 3 条子项，SELECT order_id, COUNT(*) FROM orders JOIN order_items USING(order_id) GROUP BY order_id 会返回 3，而不是 1。
- 验证方法：去掉
GROUP BY，加LIMIT 10查看原始连接结果，观察重复模式 - 解法一（推荐）：先聚合子表，再 JOIN，例如
(SELECT order_id, COUNT(*) AS item_cnt FROM order_items GROUP BY order_id) i - 解法二：用
DISTINCT在聚合内去重，如COUNT(DISTINCT order_id)或SUM(DISTINCT amount)（慎用，仅适用于金额无重复的场景）
最常被忽略的是：GROUP BY 的字段来源必须清晰来自哪张表，尤其在多表同名字段（如 id）时，不加表别名前缀极易选错列，导致分组逻辑完全错位。
