GROUP BY必须包含所有非聚合字段，JOIN后统计需用COUNT(右表字段)而非COUNT(*)，WHERE过滤行、HAVING过滤组，多层聚合优先用CTE拆解。
GROUP BY 必须包含所有非聚合字段
多表 JOIN 后用 GROUP BY，最容易出错的是 SELECT 列里混入了未参与分组、也没被聚合函数包裹的字段。比如 SELECT a.id, a.name, COUNT(b.order_id) 却只写 GROUP BY a.id —— 这在 MySQL 5.7+ 严格模式下直接报错 Expression #2 of SELECT list is not in GROUP BY clause，PostgreSQL 和 SQL Server 更是一直拒绝执行。
正确做法是：所有非聚合字段（如 a.id、a.name）都得出现在 GROUP BY 子句中：
SELECT a.id, a.name, COUNT(b.order_id) FROM users a LEFT JOIN orders b ON a.id = b.user_id GROUP BY a.id, a.name
- 别依赖 MySQL 的宽松模式，默认开启
sql_mode=ONLY_FULL_GROUP_BY才安全 - 如果
a.name和a.id是一一对应的（主键/唯一约束），某些数据库允许只写GROUP BY a.id，但跨数据库不保证，建议显式写出全部 - 用
ANY_VALUE(a.name)（MySQL）或MIN(a.name)临时绕过，但语义模糊，仅限调试
LEFT JOIN 后 COUNT(*) 和 COUNT(右表字段) 行为完全不同
聚合前没注意 JOIN 类型和 COUNT 参数，结果会少算或误算。例如统计每个用户订单数，用 COUNT(*) 会把左表空匹配行也计为 1，而 COUNT(b.order_id) 只统计右表非 NULL 值。
典型错误写法：
SELECT a.name, COUNT(*) FROM users a LEFT JOIN orders b ON a.id = b.user_id GROUP BY a.id, a.name
这会让没下单的用户也返回 1，而非 0。
- 统计「关联记录数量」必须用
COUNT(右表某列)，推荐具体字段如b.order_id，避免COUNT(b.*)（语法错误） -
COUNT(*)统计的是结果集每行，不管字段是否为 NULL - 需要补零时，确保用
LEFT JOIN+COUNT(右表字段)，这是最可靠组合
WHERE 和 HAVING 混用导致过滤逻辑错乱
想筛出「订单总额超 1000 的用户」，却把条件写在 WHERE 里：WHERE SUM(b.amount) > 1000 —— 这会报错，因为聚合函数不能出现在 WHERE 中。
正确分工：
-
WHERE在分组前过滤行（如WHERE a.status = 'active'） -
HAVING在分组后过滤组（如HAVING SUM(b.amount) > 1000） - 如果要先排除已取消订单，再算剩余订单总金额，必须
WHERE b.status != 'cancelled'；若写成HAVING，会被当成对聚合结果的二次筛选，逻辑就反了
多层嵌套聚合时优先考虑 CTE 或子查询
当需要「先按日期汇总订单，再按月份统计用户活跃度」这类两层聚合，硬塞进单条 SQL 容易逻辑缠绕、难以调试。直接写 GROUP BY 嵌套会触发语法限制，多数数据库不支持。
更清晰的做法是拆解：
WITH daily_user_orders AS ( SELECT DATE(b.created_at) AS order_date, b.user_id, COUNT(*) AS cnt FROM orders b GROUP BY DATE(b.created_at), b.user_id ) SELECT YEAR(order_date), COUNT(DISTINCT user_id) AS active_users FROM daily_user_orders GROUP BY YEAR(order_date)
- CTE 不仅可读性高，还能复用中间结果，避免重复 JOIN
- 子查询也能实现，但嵌套过深会让缩进失控，尤其涉及多个 JOIN 时
- 注意 CTE 中的
GROUP BY字段必须覆盖 SELECT 所有非聚合列，规则和外层一致
