MySQL 5.7+严格模式下GROUP BY后SELECT字段必须为分组键或聚合函数，否则报ERROR 1055；COUNT(DISTINCT user_id)统计独立用户数，CASE WHEN+SUM实现条件聚合更高效稳定，ORDER BY须基于聚合结果或窗口函数。
GROUP BY 后 SELECT 字段必须是分组键或聚合函数
写完
却报错
，这是 MySQL 5.7+ 严格模式下的典型表现。不是语法错了，是规则变了——你 SELECT 的字段里混进了没分组、也没聚合的列，比如
或
。
实操建议：
检查 SELECT 列表：每个非聚合字段（如
）必须出现在
子句中
想看每单的首件商品？用
或
（MySQL），但注意
不保证稳定性
PostgreSQL 更严格，不支持
，必须显式聚合或改用窗口函数
别依赖“以前能跑”，升级 MySQL 或换数据库后这地方最容易崩
用 COUNT(DISTINCT user_id) 算去重买家数，别用 COUNT(user_id)
统计“每个品类卖了多少独立用户”，结果比实际多一倍？大概率用了
而不是
。订单明细是行级数据，一个用户多笔订单就会被重复计数。
实操建议：
统计的是“订单行数”，
才是“人头数”
在大表上
有性能代价，如果只是判断是否购买过，可先用子查询去重再 JOIN，有时更快
注意 NULL：如果
允许为空，
自动忽略 NULL；但
会算整行，得结合业务判断要不要补漏
用 CASE WHEN + SUM 做条件聚合，比多次 WHERE 查询更稳
想同时看“已发货订单金额”和“未发货订单金额”，有人会写两个
再 UNION。问题来了：两次扫描、时间点不一致、JOIN 关联时容易错位。
实操建议：
统一用
和
别漏
：NULL 参与 SUM 会直接让整列变 NULL，不是 0
WHERE 过滤要谨慎——如果只想要“近30天”的分布，把时间条件放外层 WHERE，而不是塞进 CASE，否则逻辑易混淆
这种写法在 Hive、Spark SQL、ClickHouse 里都通用，兼容性比子查询好
ORDER BY 必须放在 GROUP BY 之后，且不能直接 ORDER BY 非聚合字段
加了
就报错？因为
没在
里，也不是聚合结果。GROUP BY 的结果集已经丢失原始行顺序，SQL 不允许按“不存在的列”排序。
实操建议：
想按“每单最新下单时间”排，得用
或
，再
如果真需要原始某一行的时间（比如首笔订单时间），得配合窗口函数：
先标序号，再过滤
MySQL 8.0+ 支持
语法糖，但本质还是要求排序字段可确定，别以为写了就万事大吉
GROUP BY 的坑不在语法难，而在它强制你面对数据粒度问题：你写的每一行，到底代表什么实体？订单？用户？时间窗口？一旦粒度没对齐，COUNT、SUM、ORDER 都会悄悄给你返错的结果。最麻烦的是——它往往不报错，只报错的数字。
GROUP BY order_idERROR 1055: Expression #2 of SELECT list is not in GROUP BY clauseproduct_namecreated_atorder_idGROUP BYMIN(product_name)ANY_VALUE(product_name)ANY_VALUEANY_VALUECOUNT(user_id)COUNT(DISTINCT user_id)COUNT(user_id)COUNT(DISTINCT user_id)DISTINCTuser_idCOUNT(DISTINCT user_id) COUNT(*)SELECT SUM(amount) FROM orders WHERE status = 'shipped'SUM(CASE WHEN status = 'shipped' THEN amount ELSE 0 END)SUM(CASE WHEN status != 'shipped' THEN amount ELSE 0 END)ELSE 0ORDER BY created_at DESCcreated_atGROUP BYMAX(created_at)MIN(created_at)ORDER BY MAX(created_at) DESCROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at)GROUP BY ... ORDER BY