应将非聚合字段加入GROUP BY子句或用聚合函数包裹；MySQL可用ANY_VALUE()或MAX()，PostgreSQL需用STRING_AGG()等，禁用ONLY_FULL_GROUP_BY仅作临时调试。
GROUP BY报错“Expression not in GROUP BY clause”怎么办
这是MySQL 5.7+和PostgreSQL严格模式下的标准行为，不是bug。只要SELECT里出现非聚合字段，又没出现在GROUP BY子句中，就会直接拒绝执行。
先确认是否启用严格模式：SELECT @@sql_mode，如果返回含ONLY_FULL_GROUP_BY，就说明是它在起作用。
- 临时调试可关掉：
SET sql_mode = (SELECT REPLACE(@@sql_mode, 'ONLY_FULL_GROUP_BY', ''))——但上线前必须改回逻辑 - 正确修复：把
name加进GROUP BY（仅当user_id与name确为1:1关系） - 更通用做法：用聚合函数包裹，如
MAX(name)、ANY_VALUE(name)（MySQL专属）、STRING_AGG(name, ',')（PostgreSQL）
GROUP BY结果行数比预期少，是不是NULL或空格搞的鬼
GROUP BY本身不会丢数据，但会把语义上“相同”的值合并——而NULL、前后空格、大小写、数字/字符串混用，都可能让本该分开的行被强行归为一组。
典型表现：查SELECT category, COUNT(*) FROM t GROUP BY category只返回3行，但SELECT DISTINCT category FROM t明明有12个值。
- 先看原始分布：
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后GROUP BY统计值失真，是不是笛卡尔积在作祟
一查订单+用户信息，二查商品+分类，三查完发现COUNT(*)翻倍、SUM(amount)暴涨——大概率是JOIN产生重复行，聚合前就已膨胀。
例如orders JOIN order_items ON orders.id = order_items.order_id，一个订单含3个商品，就会生成3行；再GROUP BY orders.id，COUNT(*)就变成3而不是1。
- 先验证：执行
SELECT orders.id, COUNT(*) FROM orders JOIN order_items ... GROUP BY orders.id ORDER BY COUNT(*) DESC LIMIT 3，看是否有明显大于1的计数 - 避免方式：先聚合再JOIN，比如用子查询或CTE先把
order_items按order_id汇总成item_count、total_amount，再和orders关联 - 别依赖
DISTINCT救场：COUNT(DISTINCT orders.id)能修数量，但对SUM()无效，且掩盖了JOIN逻辑问题
HAVING写错位置或混用WHERE，结果就不可信
HAVING只能过滤分组后的结果，不能访问单行字段；WHERE则只能在分组前筛行——两者阶段不同，混用必出错。
常见错误：SELECT department, COUNT(*) FROM employees WHERE COUNT(*) > 5 GROUP BY department，COUNT(*)在WHERE阶段根本不存在，PostgreSQL直接语法报错，MySQL宽松模式下可能执行但结果随机。
-
WHERE放业务前置条件：如WHERE status = 'active' AND created_at >= '2024-01-01'，越早过滤越高效 -
HAVING只用于分组后判断：如HAVING COUNT(*) > 10，注意HAVING status = 'active'非法，除非status也在GROUP BY中 - 别名可用性不一致：
HAVING total > 5000在MySQL可行（如果SELECT SUM(amount) AS total），PostgreSQL必须写HAVING SUM(amount) > 5000
最易被忽略的是：GROUP BY不保证顺序，ORDER BY必须显式写，且只能引用SELECT中的列或别名；另外，窗口函数（如ROW_NUMBER() OVER (PARTITION BY ...)）在需要“每组内排序取前N”时，比硬套GROUP BY可靠得多。
