GROUP BY必须包含所有非聚合字段，JOIN后统计需用COUNT(右表字段)而非COUNT(*)，WHERE过滤行、HAVING过滤组，多层聚合优先用CTE拆解。
多表 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
sql_mode=ONLY_FULL_GROUP_BY 才安全a.name 和 a.id 是一一对应的（主键/唯一约束），某些数据库允许只写 GROUP BY a.id，但跨数据库不保证，建议显式写出全部ANY_VALUE(a.name)（MySQL）或 MIN(a.name) 临时绕过，但语义模糊，仅限调试聚合前没注意 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(*) 统计的是结果集每行，不管字段是否为 NULLLEFT JOIN + COUNT(右表字段)，这是最可靠组合想筛出「订单总额超 1000 的用户」，却把条件写在 WHERE 里：WHERE SUM(b.amount) > 1000 —— 这会报错，因为聚合函数不能出现在 WHERE 中。
正确分工：
WHERE 在分组前过滤行（如 WHERE a.status = 'active'）HAVING 在分组后过滤组（如 HAVING SUM(b.amount) > 1000）WHERE b.status != 'cancelled'；若写成 HAVING，会被当成对聚合结果的二次筛选，逻辑就反了当需要「先按日期汇总订单，再按月份统计用户活跃度」这类两层聚合，硬塞进单条 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)
GROUP BY 字段必须覆盖 SELECT 所有非聚合列，规则和外层一致