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