GROUP BY结果不准确主因是数据语义问题而非语法错误：NULL被归为一组、空格/大小写导致误合并、JOIN引发笛卡尔积重复、隐式类型转换干扰分组，需逐项排查清洗。
GROUP BY结果不准确，大概率不是语法写错了，而是你没意识到SQL在按什么逻辑“合并行”——字段值是否真等价、NULL怎么算、JOIN有没有悄悄复制数据，这些才是关键。
为什么SELECT里多写一个字段就报错？
错误信息类似 ERROR 1055: Expression #2 of SELECT list is not in GROUP BY clause，这不是MySQL故意刁难，是ONLY_FULL_GROUP_BY模式在强制你回答一个问题：“这个字段在每组里到底取哪个值？”
- 查当前模式：
SELECT @@sql_mode，如果返回含ONLY_FULL_GROUP_BY，就是它在起作用 - 临时调试可关掉：
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''))，但关掉后MySQL会随机挑一行填那个字段，结果不可复现 - 真正修复分三类情况：
- 字段和GROUP BY字段是1:1关系（比如
user_id和user_name），直接加进GROUP BY子句 - 只需要统计值，不要明细字段，就从
SELECT里删掉它 - 接受“任取一个”，用
ANY_VALUE(name)（MySQL）或STRING_AGG(name, ',')（PostgreSQL）显式表达意图
- 字段和GROUP BY字段是1:1关系（比如
GROUP BY后行数比预期少，是不是数据“被吞了”？
GROUP BY不会丢数据，但它会把“看起来一样”的值归为一组。而NULL、前后空格、大小写、数字/字符串混用，都可能让本该分开的行被强行合并。
- 先看原始分布：
SELECT category, COUNT(*) FROM t GROUP BY category ORDER BY COUNT(*) DESC LIMIT 5 - 再对比清洗后：
SELECT TRIM(UPPER(category)), COUNT(*) FROM t GROUP BY TRIM(UPPER(category))，如果行数明显变多，说明空格或大小写干扰了分组 -
NULL会被当作独立一组，但容易被忽略；加WHERE category IS NOT NULL能排除，但得确认业务是否真要过滤掉这部分 - 类型隐式转换风险大：比如
user_id是INT，但想按字符串补零语义分组，得显式写GROUP BY CAST(user_id AS CHAR)
JOIN之后COUNT或SUM暴涨，是不是笛卡尔积在捣鬼？
一查订单+用户，二查商品+分类，三查完发现COUNT(*)翻倍、SUM(amount)暴涨——90%是JOIN产生重复行，聚合前数据已膨胀。
- 验证方式：
SELECT orders.id, COUNT(*) FROM orders JOIN order_items ON orders.id = order_items.order_id GROUP BY orders.id ORDER BY COUNT(*) DESC LIMIT 3，如果某orders.id对应计数远大于1，就是它 - 避免方式：先聚合再JOIN，比如用CTE先把
order_items按order_id汇总成item_count、total_amount，再和orders关联 - 别依赖
DISTINCT救火：COUNT(DISTINCT orders.id)能修COUNT，但对SUM(amount)无效，因为金额已被重复累加
GROUP BY结果顺序乱，是不是索引失效了？
GROUP BY本身不保证任何输出顺序——哪怕你刚建完主键索引，下次加个WHERE条件就可能变乱。这不是性能问题，是标准行为。
- 必须显式写
ORDER BY，且只能放在GROUP BY之后，只能引用SELECT中出现的列或其别名 - 错误写法：
ORDER BY created_at（若created_at没出现在SELECT或GROUP BY中），多数数据库直接报错 - 分组内排序要用窗口函数：
ROW_NUMBER() OVER (PARTITION BY category ORDER BY updated_at DESC)，再外层WHERE rn <= 3取每组 Top N -
GROUP_CONCAT(name ORDER BY updated_at DESC)这种MySQL特有语法能控制拼接顺序，但跨库迁移时得重写
最常被忽略的一点：GROUP BY的“准确性”根本不在语法对不对，而在你是否清楚每一行数据在聚合前的真实状态——NULL怎么处理、JOIN是否引入重复、字段值是否真的语义等价。这些问题不排查干净，改一百遍sql_mode也白搭。
