group by返回不想要的结果主因是误将其用于查明细，它只保证每组一行且未分组未聚合字段取值不可控；mysql 5.7+默认启用only_full_group_by模式，要求select中非聚合字段必须显式出现在group by子句或用max/any_value等包裹，否则报错“expression #n of select list is not in group by clause”。
GROUP BY 查询“返回不想要的结果”，90% 不是数据库出错，而是你没意识到它根本不是用来查明细的——它只保证每组一行，其余字段取值不可控。
SELECT 中出现未分组也未聚合的字段就报错
MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 模式，只要 SELECT 列表里有字段既没出现在 GROUP BY 子句中，又没套聚合函数（如 MAX()、COUNT()），就会直接报错：
Expression #2 of SELECT list is not in GROUP BY clause
- 错误写法：
SELECT user_id, name, COUNT(*) FROM orders GROUP BY user_id——name没分组也没聚合 - 修复方式一（推荐）：确认
name和user_id是 1:1 关系（比如主键关联），就加进GROUP BY：GROUP BY user_id, name - 修复方式二（慎用）：用
ANY_VALUE(name)或MAX(name)包裹，但ANY_VALUE()不跨库，且语义模糊——它真就是“随便挑一个”，不保证稳定
HAVING 里写了单行字段（比如 status = 'active'）
HAVING 只能过滤分组后的结果，不能访问原始行数据。它能用的只有：分组字段、聚合结果、以及别名（MySQL 支持，PostgreSQL 不支持）。
- 典型错误：
HAVING status = 'active'——status没在GROUP BY里，也没聚合，MySQL 宽松模式下可能执行，但结果随机 - 正确做法：前置过滤用
WHERE，比如WHERE status = 'active'；分组后过滤用HAVING COUNT(*) > 5 - 别名陷阱：MySQL 允许
HAVING total > 5000（如果SELECT SUM(amount) AS total），但 PostgreSQL 必须写HAVING SUM(amount) > 5000
GROUP BY + ORDER BY + LIMIT 返回顺序不稳定
当 ORDER BY 的列存在重复值（比如多个记录 status = 'pending'），MySQL 不保证这些记录内部的相对顺序。加上 LIMIT 后，优化器可能跳过完整排序，导致两次查询返回不同行。
- 危险写法：
SELECT * FROM tasks GROUP BY status ORDER BY status LIMIT 3 - 根本问题：分组本身不定义组内顺序，
ORDER BY status只排分组键，不排组内任意字段（如id或created_at） - 解法：如果要取每组最新一条，别硬套
GROUP BY，改用窗口函数：ROW_NUMBER() OVER (PARTITION BY status ORDER BY created_at DESC)
空结果集时，有无 GROUP BY 返回完全不同的结构
这是最容易被忽略的隐性坑：WHERE 条件没匹配到任何行时，带 GROUP BY 的查询返回 0 行；不带 GROUP BY 的标量聚合返回 1 行（含 NULL 或默认值）。
- 示例：
SELECT IFNULL(SUM(value), 0) FROM t WHERE 1=0→ 返回一行0 - 而：
SELECT IFNULL(SUM(value), 0) FROM t WHERE 1=0 GROUP BY category→ 返回空结果集（0 行） - 后果：ORM 映射时，
List<t></t>可能拿到空集合，T类型可能拿到null，包装类型（如Integer）也可能为null，逻辑分支容易漏判
真正麻烦的从来不是语法报错，而是查询跑通了却返回“看似合理”的错数据——尤其是 ANY_VALUE()、HAVING 误用、或把 GROUP BY 当明细筛选工具用的时候。
