分组计算须按业务规则分阶段执行：先where过滤、再case标记、后group by聚合，避免having复杂条件；窗口函数需嵌套在子查询或cte中，不可与普通聚合混用。
分组计算前必须明确业务规则的执行顺序
SQL 的 GROUP BY 本身不保证逻辑先后，但业务规则常隐含依赖关系（比如先过滤异常订单，再按区域聚合，最后剔除低频渠道）。直接套用 SUM() 或 COUNT() 容易把“清洗”和“聚合”混在一起，导致结果偏差。
实操建议：
- 把规则拆成明确阶段：数据筛选 → 衍生字段计算 → 分组聚合 → 后过滤
- 优先用
WHERE做前置过滤（比HAVING更高效），避免在HAVING里写复杂条件 - 对需多步判断的字段（如“是否为有效复购用户”），用
CASE WHEN提前算出布尔标记列，再在GROUP BY中引用 - 注意 NULL 处理：
COUNT(col)忽略 NULL，COUNT(*)不忽略，业务上“未填推荐人”的订单是否该计入分母，必须明确
窗口函数嵌套在 GROUP BY 中的常见误用
想在分组后做“组内排名”或“占比计算”，很多人直接写 ROW_NUMBER() OVER (PARTITION BY region ORDER BY amount) 在 SELECT 里——这会报错，因为窗口函数不能和普通聚合混用在同一层查询中。
正确做法是两层结构：
- 外层做最终分组聚合（如
region,SUM(sales)） - 内层用子查询或 CTE 先算窗口值，再把结果当普通表参与外层
GROUP BY - 示例：要算每个区域销售额 Top 3 的品类占比，得先用 CTE 算出各品类在区域内的排名，再在外层按区域聚合并过滤
rank
JOIN 后分组导致的数据膨胀问题
关联订单表和用户标签表时，一个用户有多条标签就会让订单行数翻倍，SUM(amount) 结果虚高。这不是语法错误，而是业务逻辑被 JOIN 破坏。
解决路径取决于关联类型：
- 一对多（如用户-设备）：用
MAX()、MIN()或STRING_AGG(DISTINCT tag)聚合标签，避免重复计数 - 多对多（如订单-优惠券）：先对优惠券侧单独聚合（如每单最多用几张），再 JOIN 回订单主表
- 无法避免膨胀时，改用相关子查询：
(SELECT SUM(c.amount) FROM coupon c WHERE c.order_id = o.id)替代 JOIN
MySQL 8.0+ 与 PostgreSQL 在复杂分组上的关键差异
同样写 GROUP BY a, b，MySQL 默认允许 SELECT a, b, c（c 不在 GROUP BY 中），PostgreSQL 直接报错 column "c" must appear in the GROUP BY clause。这不是兼容性问题，而是语义严谨性差异。
实际影响：
- MySQL 的宽松模式容易掩盖逻辑漏洞（比如误以为
user_name和user_id总是一一对应） - PostgreSQL 强制你显式声明聚合意图，倒逼你思考
c字段该用MAX()还是ANY_VALUE() - 跨数据库迁移时，别依赖 MySQL 的
sql_mode=ONLY_FULL_GROUP_BY关闭状态，应统一按严格模式写
复杂规则真正卡点不在语法，而在“哪一步该聚合、哪一步该过滤、哪一步该关联”。哪怕写对了 GROUP BY，只要中间漏掉一次去重或错放了 WHERE 位置，结果就不可信。
