Forest Hu聚合函数配上GROUP BY做分组计算，这大概是SQL里出现频率最高的一组搭档。我见过很多刚入行的同事，单写一句SELECT COUNT(*) FROM table没问题，单写SELECT * FROM table GROUP BY column也"能跑"，但只要把两件事揉在一起，就开始踩各种奇奇怪怪的坑：比如查询结果莫名其妙少了很多行、报错提示"不是GROUP BY表达式"、或者同一个字段换了个数据库查询结果就不一样。这篇文章就把聚合函数和分组计算的完整逻辑梳理一遍，从执行顺序到实战细节，从NULL值陷阱到性能优化，把我这些年积累的经验和踩坑记录一次讲透。
1. 分组计算到底在算什么：先理解它的业务价值
1.1 没有分组，聚合函数只会算全表总账
在学习聚合函数之前，先要搞清楚一个基础概念：聚合函数本身的作用范围是"整个结果集"。
SELECT COUNT(*) FROM orders，这句告诉你订单表里一共有多少条记录；SELECT SUM(amount) FROM orders，算的是所有订单金额的合计。当你没有加任何限制条件时，这个"结果集"就是全表数据。
这个逻辑本身很简单，但到了业务场景里就暴露问题了。假设你是电商平台的运营，老板现在想知道"每个省份分别卖了多少单、合计多少钱"。你如果只写SELECT SUM(amount) FROM orders，得到的只是全国总数，根本拆不到省份维度。这时候就需要GROUP BY出场：它的作用是把一张大表按指定的列切分成多个小组，然后聚合函数在每个小组内部单独计算。这就是"分组计算"的本质——GROUP BY province会把订单按省份拆成若干堆，SUM(amount)在每个省自己的数据堆里各自求和，最终每个省得到一行结果。
1.2 分组计算解决的是一类典型的"按类汇总"问题
"分组"这个动作，说穿了就是"找出数据之间的共同特征，然后按类别归堆"。这一类需求在数据分析中的出现频率极高，几乎每天都躲不开：
- 按时间维度汇总：统计每个月的销售额、每天的用户注册量、每小时的接口调用次数。
- 按分类维度汇总：统计每个品类的库存总量、每个部门的平均薪资、每台机器的CPU使用率峰值。
- 按多条件组合汇总：统计每个省份每个月的订单量、每个仓库每种商品的库存数。
有一次我接手一个报表需求，业务方要"每个销售大区下每个产品线的季度回款率"，这就是典型的多列分组场景，一个GROUP BY后面跟了两个分组列（大区、产品线），再配合时间维度的表达式分组，一条SQL就搞定了。如果你是掌握不好GROUP BY的人，碰到这种需求大概率会写一堆子查询再手动用Excel拼表，麻烦不说，还容易出错。
GROUP BY的价值，在于把"分类+汇总"这件事下沉到数据库引擎去完成，少传数据、少写代码、结果可靠。这也是它成为SQL核心语法之一的原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 到底什么时候执行GROUP BY：别再用"从上到下"的思维看SQL
很多初学者想不明白一个问题：既然GROUP BY是对数据分组，那我能不能直接从FROM table WHERE condition GROUP BY column一路从左读到右？其实SQL的执行顺序和书写顺序完全不同，而理解这个顺序，是搞懂分组计算的关键前提。
2.1 SQL逻辑执行顺序
一条标准的分组查询语句，书写的顺序是：
sql复制SELECT 类别列, 聚合函数(数值列)
FROM 表名
WHERE 过滤条件
GROUP BY 类别列
HAVING 聚合后的过滤条件
ORDER BY 排序列;
但数据库引擎实际执行的逻辑顺序是：
- FROM：先确定数据来源，取出一张表或临时表。
- WHERE：对FROM得到的每一行记录做过滤，把不满足条件的行直接丢弃。
- GROUP BY：把WHERE过滤后剩余的行按分组列的值分成若干组。
- 聚合：在每个组内分别执行聚合函数计算。
- HAVING：对聚合完成后的分组结果做过滤，不满足条件的分组被丢弃。
- SELECT：投影出最终要返回的列。
- ORDER BY：对返回结果做排序。
看到没有，GROUP BY是在WHERE之后执行的。这意味着，凡是写在WHERE里的条件，都是在分组之前就过滤掉了；凡是写在HAVING里的条件，都是在分组聚合之后才过滤的。这个顺序上的差异，直接决定了SQL语句的语义和性能。
2.2 用执行顺序解释一个经典报错
执行顺序还能解释一个几乎每个SQL初学者都会遇到的报错：SELECT column_name FROM table GROUP BY other_column，系统直接提示列名无效或者"不是GROUP BY表达式"。
原因就在于执行顺序：SELECT是第六步，GROUP BY是第三步。你SELECT里出现了某个普通列，可是这个列既没有出现在GROUP BY中，也没有被包裹在聚合函数里，那数据库就不知道从组里哪一行取这个值。每个组里这个列可能有多个不同的值，你让数据库输出哪一个？所以大部分数据库（MySQL的ONLY_FULL_GROUP_BY模式、PostgreSQL、Oracle、SQL Server）都会直接报错。
这里多说一句：MySQL默认关闭了ONLY_FULL_GROUP_BY的话，上面这种"不规范写法"也能跑通，它只会随机取组内某一行的值。这个行为非常坑，因为它往往不报错，但结果不可控。我见过有人因此得出错误的统计结果，排查半天才发现是这个原因。建议在你的MySQL配置里打开sql_mode='ONLY_FULL_GROUP_BY'，从根源上避免这种隐患。
2.3 一条SQL走完整个分组流程
为了让你对执行顺序有个直观的印象，我拿一个真实的订单场景走一遍流程：
表结构：订单表orders，包含order_id（订单号）、city（城市）、amount（金额）、order_date（下单日期）。
sql复制SELECT city, COUNT(*) AS order_cnt, SUM(amount) AS total_amount
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY city
HAVING COUNT(*) > 10
ORDER BY total_amount DESC;
执行流程是这样的：
- FROM阶段，拿到orders表全部数据。
- WHERE阶段，过滤掉2024年1月1日之前的订单。
- GROUP BY阶段，剩下的订单按city分组，北京一组、上海一组、广州一组……
- 聚合阶段，每组分别统计订单数和金额合计。
- HAVING阶段，丢掉订单数不超过10的城市。
- SELEC