企业官网建设流程全解析

干过几年数据分析的人，几乎没有谁没被 GROUP BY 折腾过。它看起来只是把相同行归到一起，但一旦牵扯到聚合函数、多字段分组、数据库模式设置和索引优化，各种隐藏细节就全冒出来了。这篇内容是我这些年写报表、做数据清洗和优化慢查询时，对 GROUP BY 如何实现数据分组统计的完整梳理。适合刚学 SQL 的初学者，也适合已经写过不少查询、但偶尔会对分组结果“看着没问题却总觉得不对”的开发者。读完之后，你不仅能写对 GROUP BY，还能解释清楚它背后的执行逻辑，以及为什么会慢、该怎么调。

1. GROUP BY 到底在做什么：先建立正确的执行心智模型

1.1 分组不是“去重”，而是“把行装进篮子”

我见过太多新手把 GROUP BY 误解成“去重plus”。其实这两个操作的结果有时看起来像，但心智模型完全不同。去重是丢掉重复行，只保留一份；分组是把所有行按照某一列或某几列的值，装进对应的“篮子”里。一个篮子里可能装了几百行，这些行原封不动，只是等待下一步被统计。

拿现实场景举例。你有一箱子混合颜色的袜子，要做库存统计。GROUP BY color 就相当于先把袜子按颜色分堆，红色一堆、蓝色一堆、白色一堆。分完之后，你数每一堆有多少只袜子，这就是 COUNT；称每一堆的重量，这就是 SUM。所以 GROUP BY 的真正产出是“若干组数据”，组的数量等于不同分组值的个数，而组内行数就是聚合函数要处理的数据范围。

这个理解非常关键。因为它解释了为什么 SELECT 里只能出现分组列或聚合结果：其他字段在组内是“不确定的”，比如同是北京组，里面可能有一百行订单，每一行的 customer_id 都不一样，直接 SELECT customer_id 数据库不知道该给你哪一个。

1.2 一条 GROUP BY 语句的真实执行顺序

很多人以为 SQL 是从上往下按关键字顺序执行的，其实不是。SQL 有固定的逻辑执行顺序，理解它才知道 WHERE 和 HAVING 的区别在哪。

标准逻辑顺序大致是：

1. FROM：确定从哪张表取数，如果有 JOIN 就先做连接
2. WHERE：对原始行做过滤，把不需要的行提前扔掉
3. GROUP BY：把留下的行按分组键装进篮子
4. HAVING：对分组后的每一组做过滤，决定哪些组保留
5. SELECT：计算分组结果，包括聚合函数、表达式、别名
6. ORDER BY：对最终结果排序
7. LIMIT / OFFSET：截取部分行

注意，物理执行时数据库可能会优化，比如某些子查询会提前物化，但你在写 SQL 时按这个顺序思考永远不会出大错。

这个顺序解释了一个最常见的坑：为什么 WHERE 里面不能写聚合函数？因为 WHERE 执行的时候分组还没发生，你上哪去找 COUNT(*)？数据库根本不知道每个组有多少行。而 HAVING 在 GROUP BY 之后执行，此时每个组已经成型，聚合函数当然能用。这就是“先有分组，后有组过滤”的含义。

1.3 WHERE、GROUP BY、HAVING 三者分工不同

用一句话总结三者的分工：

• WHERE：行级过滤，发生在分组之前。它管的是“哪些订单参与统计”
• GROUP BY：定义分组维度。它管的是“按什么维度把数据分成几堆”
• HAVING：组级过滤，发生在分组之后。它管的是“哪些组能出现在结果里”

我用同一张订单表举个例子说明差异。

查询一：统计 2024 年每个城市的订单总金额

SELECT city, SUM(amount) AS total FROM orders WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31' GROUP BY city;

WHERE 先把非 2024 年的行过滤掉，剩下的行再按城市分组，所以“2024 年”这个条件影响的是每一行是否参与统计。

查询二：统计订单总额超过 10 万元的城市

SELECT city, SUM(amount) AS total FROM orders GROUP BY city HAVING SUM(amount) > 100000;

这里不能把 SUM(amount) > 100000 放到 WHERE 里，因为 WHERE 在分组前执行，SUM 还不存在。

提示：能先用 WHERE 过滤的行级条件，尽量不要放进 HAVING。先减少数据量再分组，性能和逻辑都更清晰。HAVING 适合保留“关于整个组的条件”，而非单行条件。

2. 从单字段到多字段：分组统计的实操要点

2.1 单字段分组：最基础的分组统计写法

假设有一张销售订单表 orders，字段包括 order_id、customer_id、city、channel、amount、order_date。最经典的单字段分组是这样：

SELECT city, COUNT(*) AS order_cnt, SUM(amount) AS total_amt FROM orders GROUP BY city;

执行后每个城市一行，前面 GROUP BY 按 city 分堆，COUNT(*) 数每一堆有几行，SUM(amount) 累加每一堆的金额。

这里有一个很容易被忽略的细节：COUNT() 和 COUNT(order_id) 不一样。COUNT() 统计组内所有行数，哪怕某一行所有字段都是 NULL 它也会计入；而 COUNT(order_id) 只统计 order_id 非 NULL 的行数。如果你的业务是统计“订单数”，一般用 COUNT(*) 或 COUNT(主键) 都行；但如果某列允许为空，务必想清楚你要的是“该列有值的行数”还是“总行数”。

2.2 多字段分组：group by 多个字段的组合语义

“group by 多个字段”是 GROUP BY 使用频率最高、也最容易写迷糊的场景。看这个查询：

SELECT city, channel, COUNT(*) AS order_cnt, SUM(amount) AS total_amt FROM orders GROUP BY city, channel ORDER BY city, channel;

这里的分组键不是“城市”也不是“渠道”，而是“城市 + 渠道”的组合。也就是说，北京线上、北京线下、上海线上、上海线下，这些组合只要在数据里出现过，就会各自成为一个组。

结果大致长这样：

多字段分组时，字段顺序在逻辑上不影响分组结果，因为 (city, channel) 和 (channel, city) 产生的组粒度是相同的。但要注意两点：一是排序时数据库可能按分组字段的输出顺序排列，所以带 ORDER BY 总是更稳妥；二是当你把一个字段写进 SELECT 却没有把它放进 GROUP BY 时，SQL 标准会直接报错，这一点我在后面单开一节讲。

2.3 聚合函数选型与空值处理

分组统计离不开聚合函数，常用的是 COUNT、SUM、AVG、MAX、MIN。它们对 NULL 的处理规则一定要记牢：

• SUM 会忽略 NULL，但一个组内所有该列值都是 NULL 时，SUM 返回 NULL，不是 0
• AVG 只对非 NULL 值求平均，分母是“非空行数”而不是“总行数”
• MAX、MIN 忽略 NULL
• COUNT(列名) 忽略 NULL，COUNT(*) 不忽略

打印报表的时候，SUM 结果是 NULL 会很麻烦，接口里会出现空值，前端可能显示空白。通常我会这样处理：

SELECT city, COALESCE(SUM(amount), 0) AS total_amt FROM orders GROUP BY city;

COALESCE 把 SUM 的 NULL 结果替换成 0，整个报表输出就不会出现“合计金额为空”的怪现象。这个细节在跑月报、对账时特别有用。

2.4 别在 SELECT 里写游离字段

SQL 标准规定：SELECT 中的非聚合列必须出现在 GROUP BY 中。否则数据库无法确定该从组内哪一行取这个字段。

但 MySQL 在关闭 ONLY_FULL_GROUP_BY 模式时允许这种写法：

SELECT customer_id, city, SUM(amount) FROM orders GROUP BY city;

这条语句在宽松模式下能执行，但 customer_id 到底取组内哪一行，数据库“随意”选择，结果没有任何确定性。同一份数据，今天跑和明天跑，甚至数据库版本升级后跑，返回的 customer_id 都可能不同。

我排查过这样一个线上问题：开发在统计客单价时没把 customer_id 纳入分组，结果报表里的客户 ID 张冠李戴，财务对账对不上。这种错误特别隐蔽，因为它不报错，只有仔细核对才能发现。

注意：MySQL 5.7 及以上默认开启 ONLY_FULL_GROUP_BY，写游离列会直接报错。但如果你在维护老系统，或者开发环境把 sql_mode 改了，这种“合法但不合理”的 SQL 依然会出现。写 GROUP BY 时，问自己一句：SELECT 里除了聚合函数，其他列是不是都在 GROUP BY 里？不在就加进去。

3. 进阶场景：ROLLUP、GROUPING SETS 与编程语言对照

3.1 用 GROUP BY 实现多层次汇总：ROLLUP 与 GROUPING SETS

纯 GROUP BY 只能得到“按某个维度分组”的结果。但实际报表往往需要“既看明细分组，又看小计、总计”。比如按城市和渠道统计完，还想看到整个城市的合计、整个公司的总计。

传统做法是用 UNION ALL 把多种分组结果拼起来，SQL 又长又难维护：

SELECT city, channel, SUM(amount) AS total FROM orders GROUP BY city, channel UNION ALL SELECT city, NULL, SUM(amount) FROM orders GROUP BY city UNION ALL SELECT NULL, NULL, SUM(amount) FROM orders;

这种写法能用，但重复扫描三次表，性能差，而且后期加一个维度字段就要改一大段。更优雅的是用 ROLLUP：

SELECT city, channel, SUM(amount) AS total FROM orders GROUP BY ROLLUP(city, channel);

它会在常规分组结果之外，额外生成小计行和总计行：上海线上、上海线下两行结束之后，会出现一行 city=上海、channel=NULL 的小计；最后出现一行 city=NULL、channel=NULL 的全表总计。在报表工具里，这一行 NULL 通常会被显示成“合计”。

GROUPING SETS 更灵活，可以手动指定需要哪些分组组合：

SELECT city, channel, SUM(amount) AS total FROM orders GROUP BY GROUPING SETS ((city), (channel), ());

结果里只有按城市的分组、按渠道的分组，以及总计，不再出现 (city, channel) 这种交叉明细分组。CUBE 则会生成所有可能的分组组合，适合多维分析，但要谨慎使用，组合数量随维度数指数增长，数据量大时会非常重。

3.2 COUNT(DISTINCT ...) 的正确用法

有一个高频需求是“统计每个城市有多少个不同客户”：

SELECT city, COUNT(DISTINCT customer_id) AS customer_cnt FROM orders GROUP BY city;

COUNT(DISTINCT 列) 在组内先去重再计数，结果不受重复订单影响。这是 GROUP BY 最常见的进阶用法之一。

但要怀有敬畏心：COUNT(DISTINCT ...) 比 COUNT(*) 慢得多。数据库需要对指定列做排序或哈希去重，行数一旦到千万级，这条 SQL 可能成为慢查询榜首。如果业务上每天只需要一个“活跃客户数”，可以考虑提前做每日预聚合，把明细行的 distinct 计算放在离线任务里，在线查询只读结果表。

3.3 用 Java 的 group 操作对照着理解

“group()+数组java”是最近搜索 GROUP BY 时经常一起出现的词。虽然语言不同，但分组聚合的模型是相通的。Java 8 的 Stream 提供了 groupingBy 收集器：

Map<String, Long> countByCity = orders.stream() .collect(Collectors.groupingBy(Order::getCity, Collectors.counting()));

这段代码等价于 SQL 中的 SELECT city, COUNT(*) FROM orders GROUP BY city。groupingBy 先把订单按城市分组到 Map 的 key，value 是同一个城市的订单集合，然后 counting() 对这个集合计数。

SQL 的 GROUP BY 和 Java Stream 的 groupingBy，本质上都遵循同一个两步模型：先分组，再对每个组做归约。理解了这个模型，你在跨界阅读代码或写报表时就不容易迷失。很多用 Java 写的报表服务，底层就是把数据库查出来的明细 List 拉到内存里，再用 groupingBy 做二次统计，逻辑和 SQL 完全对应。

3.4 从明细到报表：一个综合场景拆解

SAP Group Reporting 这类合并报表产品，虽然界面复杂，但底层核心逻辑无非是把多家公司的数据按“公司代码 + 会计期间 + 科目”分组，然后做汇总和抵消调整。你可以把它理解成一个大号的 GROUP BY 应用：维度是公司、期间、科目，聚合函数是 SUM、AVG 等，再叠加各种合并规则。

我们用一个轻量版报表来模拟这个思路。假设销售数据表 sales 有月份、部门、产品、金额四个字段，现在需要统计每个月份、每个部门、每个产品的销售额：

SELECT DATE_FORMAT(order_date, '%Y-%m') AS month, dept, product, SUM(sales_amount) AS sales FROM sales WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31' GROUP BY month, dept, product ORDER BY month, dept, product;

这个查询有四个值得注意的地方：

第一，WHERE 先把年份限定住，避免全表扫描全年数据。第二，GROUP BY 使用了三个字段，维度组合的粒度就是“月 + 部门 + 产品”。第三，SELECT 里 month 是 DATE_FORMAT 表达式，GROUP BY 也写了 month 这个别名。在 MySQL 中可以这样玩，但 Oracle 等数据库不允许 GROUP BY 使用列别名，为了保证跨库迁移，更稳妥的写法是把 DATE_FORMAT(order_date, '%Y-%m') 原样写在 GROUP BY 中。第四，ORDER BY 统一排序，保证报表输出顺序稳定。

4. 性能调优：为什么你的分组查询越来越慢

4.1 索引对 GROUP BY 的作用

很多人以为 GROUP BY 慢是因为数据量大，其实很多时候是索引没用上。GROUP BY 的核心操作是“按分组键归类数据”，如果分组键上有合适的索引，数据库可以直接按索引顺序读取，省去排序和临时表。

以 city、channel 多字段分组为例，在 MySQL 中建一个联合索引：

CREATE INDEX idx_city_channel ON orders(city, channel);

然后执行：

EXPLAIN SELECT city, channel, SUM(amount) FROM orders GROUP BY city, channel;

如果执行计划里出现 Using index for group-by，说明数据库已经把分组键的索引用上了，数据按索引顺序扫描即可完成分组，不需要额外排序。

注意联合索引的字段顺序要匹配 GROUP BY 的字段顺序。GROUP BY city, channel 通常能利用 (city, channel) 索引，但 GROUP BY channel, city 就不一定能用上，因为索引最左前缀原则要求从最左侧字段开始匹配。

4.2 临时表与排序：那些年我们追过的 filesort

分组键上没有索引时，数据库常见的做法是把数据放到临时表里，再做排序和分组。在 EXPLAIN 的 Extra 列里，你会看到两个很不好的字眼：

• Using temporary：用了临时表
• Using filesort：额外做了一次文件排序

两者同时出现，基本说明这条 GROUP BY 查询在数据量上涨后会越来越吃力。优化方向只有一个：尽量让分组键走索引，避免临时表和排序。

如果表实在太大，且分组维度是固定的，可以考虑建汇总表。比如每天凌晨用定时任务跑一遍“按城市、渠道统计前一天的订单汇总”，写入一张 summary_orders 表。线上报表只查这张汇总表，几百行数据秒开，不必每次都去扫几千万行的明细表。这个思路在电商大促报表、财务日结算里属于标准做法。

4.3 避免隐式转换和函数包裹

在 GROUP BY 列上做函数操作，往往会让索引失效。最典型的反面教材：

SELECT DATE(order_date) AS d, SUM(amount) FROM orders GROUP BY DATE(order_date);

逻辑上没问题，按日期分组，但 DATE(order_date) 把列包裹了一层函数，数据库无法直接使用 order_date 上的索引，只能全列扫描。如果数据量不大问题不明显，积到几千万行就会变成慢查询。

正确做法是用范围条件表达“按天”：

SELECT order_date, SUM(amount) FROM orders WHERE order_date >= '2024-01-01' AND order_date < '2024-01-02' GROUP BY order_date;

WHERE 里也别写 WHERE DATE(order_date) = '2024-01-01'，换成范围写法，让索引能用上。这是我调过无数慢查询后的统一结论：函数包裹列名，短期图方便，长期还债。

注意：如果业务里“按日分组”是高频操作，方案不是去优化同一个表达式，而是把日期拆成冗余字段，或者用生成列建立索引。在存储层面先解决问题，比在 SQL 层面打补丁更彻底。

4.4 实践建议：写分组查询时先看这三件事

我每次优化 GROUP BY 慢查询，都会按固定顺序检查：

• 第一，WHERE 条件能不能过滤掉大量无关行？比如时间范围、状态值，先缩小数据集。
• 第二，GROUP BY 字段在索引里吗？在的话执行计划是否出现 Using index for group-by？
• 第三，HAVING 过滤条件里有没有特别重的聚合函数？COUNT(DISTINCT ...) 往往是性能杀手。

常犯的另一个问题是 LIMIT 的位置。有人以为 LIMIT 会在分组前生效，能给 GROUP BY 减负，实际上 LIMIT 发生在分组排序之后。如果你想“取金额最大的前10个城市”，必须先 GROUP BY 再 ORDER BY 再 LIMIT，这是正确顺序；如果你因为担心慢就 LIMIT 写得太小，结果却一样慢，那是因为前面已经完成了全部分组计算，LIMIT 只是最后截取了结果。真到这一步，就得靠索引或汇总表来解，而不是靠 LIMIT。

5. 常见问题与排查技巧实录

5.1 分组查询常见报错速查表

这些年踩过和帮别人踩过的坑，集中整理成下表：

最后一个情况值得多说一句：GROUP BY 会把 NULL 当作一个独立分组值。比如城市字段有空值，结果里会多出一行 city=NULL 的分组，里面统计的是那些没填城市的订单。这在报表里经常被误认为是数据错误，其实是行为符合定义的。处理方式看业务需要，如果这些空值行没有分析意义，就在 WHERE 里排除；如果还要保留，可以在 SELECT 里用 COALESCE(city, '未知') 转义显示。

5.2 分组后想筛选组怎么办：HAVING 的正确打开方式

需求是“找出订单数超过 10 个的城市”，正确写法是：

SELECT city, COUNT(*) AS order_cnt FROM orders GROUP BY city HAVING COUNT(*) > 10;

注意 HAVING 和 WHERE 的分工。WHERE 在分组前过滤，HAVING 在分组后过滤。千万不要试图用 WHERE COUNT(*) > 10 这种写法，它根本不会执行。反过来说，如果 HAVING 里出现了诸如 city = '北京' 这种和聚合无关的条件，先把它拆出来放进 WHERE，性能更好。因为 WHERE 能提前减少参与分组的行数，HAVING 却要在分组完成后才过滤。

5.3 GROUP BY 与 DISTINCT 怎么选

SELECT DISTINCT city, channel FROM orders 和 SELECT city, channel FROM orders GROUP BY city, channel 在很多场景下结果一样：都返回城市加渠道的去重组合。那两者怎么选？

我的习惯是：只是想知道有哪些组合值，用 DISTINCT，意图更明确；需要统计每个组合的行数、金额、平均数，必须用 GROUP BY。GROUP BY 的底层能力是分组，DISTINCT 的底层能力是去重，两者在部分数据库上执行计划可能一致，但语义不同。写代码给同事看，意图清晰比什么都重要。强行用 GROUP BY 去重，很多时候只是让阅读者多猜一步“你的分组到底想要聚合什么”。

5.4 网上搜 GROUP BY 资料时别被“热点词”带偏

我记得有段时间搜 GROUP BY 相关的优化教程，后面总是自动带出一些奇怪的热词，比如 SAP Group Reporting、Java 的 groupingBy，连 Windows 的 Group Policy 报错也在里面。这里提醒一下初学者：看到这些词先判断是否相关。SAP Group Reporting 和 Java groupingBy 确实和分组思想沾边，理解它们对扩展视野有帮助；但有些字面带“group”的词和 SQL 没有半点关系，比如 Group Policy 服务登录失败，那是 Windows 域环境的问题，拿到 SQL 场景里只会浪费时间。

搜索学习资料时，我通常只看两类来源：官方文档和可靠社区的高赞回答。官方文档里 GROUP BY 的语法、限制、执行计划解释是最权威的，社区回答能补充真实案例。关键词用“GROUP BY 执行顺序”“GROUP BY 索引优化”“GROUP BY 多字段+出错”这类组合，比只搜“GROUP BY”精准得多。

我个人实际项目里的经验是：GROUP BY 用得好不好，直接决定了报表查询是秒开还是卡死。它不是一个需要炫技的语法，而是一个需要理解语义、熟悉边界、懂得用索引护航的基础能力。每次写完分组查询，请你多看一眼 WHERE 的条件、GROUP BY 的字段、SELECT 里有没有游离列，这三步检查做完，大多数坑就绕过去了。