一个 SQL 查询在报表里占的篇幅常常比业务代码还多。而其中最绕不过去的语法就是select ... group by。不管你是写后端接口、做数据分析还是维护数据库只要手头有“按某个维度汇总出结果”的需求最后基本都会落到这条语法上。它解决的就是一类非常朴素的场景把一个表里的数据按某个字段折叠成几组再对每组算个数、求和、取平均。它适合所有刚接触 SQL 的新手也适合那些“每次 group by 都靠试碰上聚合报错就懵”的开发老手。这篇文章我会把执行顺序、字段选择规则、多字段分组、having 过滤这些核心细节一次讲透再附上可以直接抄的实战用例以及我实际踩过的一组坑。1. select ... group by 到底是什么一条 SQL 是怎么干活的1.1 很多人搞反了 SQL 的执行顺序先看一个最常见的错误认知拿到select department, count(*) from employees group by department这条 SQL大多数人脑子里跑的顺序是“先 select再 count最后 group by”。这个理解是反的。SQL 的实际执行顺序大致是FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT也就是说SELECT是整个流程里倒数第二步GROUP BY在它之前就已经把数据分好组了。真正的工作方式是先拿 FROM 指定的表然后用 WHERE 把不需要的行过滤掉接着按照 GROUP BY 后面的字段把所有剩余行分成一个个“桶”再对每个桶执行聚合计算最后才是 SELECT 把要输出的列挑出来。这个顺序为什么重要因为很多人写select process_status, avg(handle_time) from work_order where status 1 group by process_status时会下意识以为是“先 select process_status、avg(handle_time)再 group”一旦报错就不知道错在哪。实际上avg(handle_time)是分组之后才逐组计算的WHERE status 1又必须在分组之前把数据缩小。记住这个链条后面所有疑难基本都能自己推出来。我用一个生活化的类比帮你固化这个顺序你有一堆水果先要把烂掉的挑出来扔掉WHERE再把剩下的按品种分到不同篮子里GROUP BY最后数每个篮子里有几个COUNT/SUM/AVG挑出篮子里最重的那一个MAX最后才轮到“报结果”。如果你一开始就伸手去数总共有几个水果那在烂果还没被扔掉的前提下数出来的东西根本不是你要的。SQL 的顺序逻辑和这套流程是一样的。还有一个容易被忽略的点ORDER BY发生在 SELECT 之后所以它可以使用 SELECT 里的别名而WHERE不行。比如select department as d, count(*) as cnt from employees group by department having cnt 5 order by cnt desc里GROUP BY后面不能直接引用别名d但ORDER BY可以用cnt。这个差异背后的原因就是执行的先后顺序理解了顺序就不会记混。1.2 GROUP BY 之后SELECT 里到底能放什么列标准 SQL 里有一条很硬核的规则SELECT 子句中出现的非聚合列必须全部出现在 GROUP BY 子句中。也就是说如果你group by department那 SELECT 里只能出现 department 这种分组列或者count(*)、sum(salary)这类聚合函数不能随意写一个不在分组里的普通列比如 name。这条规则很多人是在报错里学到的。MySQL 5.7 默认开启ONLY_FULL_GROUP_BY模式一旦你select name, count(*) from employees group by department就会得到一个错误提示which is not functionally dependent on columns in GROUP BY clause。更早期的 MySQL 没有这个限制会“随机”从每个分组里取一条 name 给你。我在老项目迁移数据库版本时见过一次真实事故原本能跑通的查询在升级后突然挂了代码里外层套一层子查询内部就违反了这个规则。所以从今天开始无论你用什么数据库都把“SELECT 非聚合列必须等于 GROUP BY 列”这条当成铁律别依赖旧版本给出的宽容结果。那如果就是想看每个分组里某个人的姓名呢比如想取每个部门工资最高的员工的姓名。办法不是写在同一个聚合逻辑里硬拼而是用子查询或者窗口函数。窗口函数row_number() over (partition by department order by salary desc)是更清爽的做法这属于 GROUP BY 的延伸方案后面实战部分我会给一段可以直接用的写法。这条规则的边界在有些数据库上有例外如果某个普通列对分组列存在函数依赖即给定一个 department 就能唯一确定一个值那 SELECT 里写这个列也是允许的。比如employees表里department是主键department_name依赖它那么select department, department_name, count(*) ... group by department在 PostgreSQL 和 MySQL 的新版本里是可以合法执行的。理解成“只要这个列的值在一个分组内肯定只有一个就没问题”就够日常使用了。2. 写分组查询前你必须先把这几个细节弄明白2.1 group by 多个字段它到底在按什么分组GROUP BY后面跟两个字段比如group by department, position意思是把这两个字段的取值组合当成一个复合分组键。换句话说“销售部-经理”是一组“销售部-主管”是另一组“技术部-经理”又是一组。它并不是先按 department 分完再在每组内部按 position 细分而是一次性把多列拼成一个键去做分组。效果上你可以理解为把这两个列拼成一个“中间字符串”再分组最直白也最不容易出错。写多字段分组时有几个实践上的建议。第一GROUP BY后面各列的先后顺序不影响分组结果group by department, position和group by position, department得到的行集合完全一样但输出结果的默认排列顺序可能会有差异这取决于数据库的实现在排序时是按哪些列排序的。第二SELECT里出现的普通列要和GROUP BY里的列集合一致顺序无所谓但要全。第三有的老派写法会写group by 1, 2直接用 SELECT 列的序号这在 MySQL 里被支持但我不建议用一旦修改 SELECT 的列顺序分组逻辑就会悄悄改变排查起来极其痛苦。好的习惯是永远写出完整的列名。多字段分组最常见的应用场景是“按年月统计”和“按区域加城市统计”。group by extract(year from create_time), extract(month from create_time)或者直接group by date_format(create_time, %Y-%m)这类需求几乎每个报表项目都会碰见。如果你还需要同时保留每一行明细的原始日期又想做月度汇总可以在分组里只写日期截断后的表达式也可以额外用GROUPING SETS这类高级语法做多层次的汇总后面我会举例子。2.2 where 和 having一个过滤行一个过滤组WHERE和HAVING的边界问题是我在面试新人时最喜欢问的。两者的本质区别是WHERE发生在分组之前负责过滤“行”HAVING发生在分组之后负责过滤“组”。所以WHERE里不能写聚合函数因为分组之前还没有任何聚合结果可用HAVING里可以使用聚合函数因为它就是在分组完成之后针对每组的结果做判断。举个例子统计“人数超过 100 人的部门”。你要过滤的是“部门”这个组不是员工行所以必须用HAVING count(*) 100。而“只统计在职员工”就应该用WHERE status active因为那是针对每一行员工状态的判断。如果你非要在 WHERE 里写count(*) 100数据库会直接报一个“invalid use of group function”之类的错误。性能上还有个非常重要的工作习惯能用 WHERE 过滤掉的千万别留到 HAVING。原因是 WHERE 可以在扫描阶段就减少参与分组的行数甚至通过索引直接跳过大量数据而 HAVING 必须等分组和聚合全部算完才能做过滤。一次分组需要创建临时结构、扫描分组键、累加聚合结果数据量一大提前用 WHERE 缩小范围能省下一大截时间。写分组查询时先问自己一句这个条件是针对原始行的还是针对分组结果的前者放 WHERE后者放 HAVING不要混。还有一个 SELECT 语句完整链条的常见陷阱GROUP BY可以引用 SELECT 中没出现过的列。比如select department, count(*) from employees group by department, position分组粒度比输出粒度更细这是合法的。此时两个不同的 department 组里如果 position 不同会被拆成更多分组但 SELECT 输出时 department 会重复出现多行。这算是最容易让人困惑但实际并不罕见的情况写的时候要清楚自己输出的行粒度到底是哪一个层级。2.3 聚合函数每个函数对 NULL 的态度都不一样COUNT、SUM、AVG、MAX、MIN是分组时最常用的五个聚合函数但它们对NULL的处理方式差异很大这是隐蔽的坑。COUNT(*)统计的是组内行数不管这行某列是不是 NULL都会算进去。COUNT(column)只统计该列不为 NULL 的行数。如果某列 10 行里有 3 行为 NULLCOUNT(column)返回 7。SUM(column)自动跳过 NULL等价于SUM时把 NULL 当 0。所以在没有行的分组里SUM返回 NULL不是 0。AVG(column)也是跳过 NULL 的分子分母都把 NULL 排除。假设一组有 5 行其中 2 行 salary 为 NULLAVG(salary)计算的是 3 行的平均值。MAX、MIN同样忽略 NULL只有该组全为 NULL 时才返回 NULL。这几条规则在报表里影响非常大。比如统计员工平均工资如果没注意 NULL算出来的平均值其实是“有工资记录的人的平均值”和“全员平均值”是两个概念。想强制忽略还是保留 NULL可以用COALESCE(column, 0)这种写法提前把 NULL 转成 0但转成 0 之后分母也会变化你得明确自己到底想要哪个口径。MySQL 还有一个很实用的聚合函数叫GROUP_CONCAT可以把组内某个列的值拼成一个字符串比如把每个部门的所有员工姓名用逗号连起来。PostgreSQL 对应的是STRING_AGGSQL Server 对应的是STRING_AGG或FOR XML PATH。这类函数在导出汇总清单时特别方便但要注意拼接字段长度上限超长会被静默截断这属于“看起来很简单真出事时很隐蔽”的坑。3. 一套能直接抄的 group by 实战用例3.1 建表和造数据别光看理论先自己跑一遍光讲概念记不牢我建议你直接开个数据库把这套用例跑一遍。这里我用一套“订单明细表”做演示场景是电商后台常见的统计需求。表结构如下CREATE TABLE orders ( id INT PRIMARY KEY, region VARCHAR(50), department VARCHAR(50), category VARCHAR(50), amount DECIMAL(10,2), created_at DATE ); INSERT INTO orders VALUES (1, 华东, 销售部, 数码, 1200.00, 2024-01-05), (2, 华东, 销售部, 家电, 2300.00, 2024-01-12), (3, 华东, 运营部, 数码, 800.00, 2024-01-20), (4, 华北, 销售部, 家电, 4500.00, 2024-02-03), (5, 华北, 销售部, 数码, 3200.00, 2024-02-10), (6, 华北, 运营部, 数码, 1500.00, 2024-02-18), (7, 华东, 运营部, 家电, 600.00, 2024-03-01), (8, 华南, 销售部, 数码, 2900.00, 2024-03-08), (9, 华南, 运营部, 家电, 1800.00, 2024-03-15), (10, 华南, 销售部, 数码, 2600.00, 2024-03-22);有了这份数据下面所有演示你都能在自己机器上复现。我组里的新人一般跑完这几条再回去看书效率比先背书再上手高得多。3.2 7 个高频查询逐行拆解第一个是最基础的单字段分组统计每个销售部门的订单笔数SELECT department, COUNT(*) AS order_cnt FROM orders GROUP BY department;输出就是按部门折叠后的行数每行代表一个部门。第二个是多字段分组统计每个区域下每个部门的销售额合计SELECT region, department, SUM(amount) AS total_amount FROM orders GROUP BY region, department;这里region, department会被拼成复合键你一眼就能看出哪些区域哪些部门卖得多。如果只想按department汇总只写一个字段即可输出行数会少很多。第三个是带上 WHERE 前置过滤的场景只统计 2024 年 2 月之后的数码类订单再按部门汇总SELECT department, COUNT(*) AS order_cnt FROM orders WHERE category 数码 AND created_at 2024-02-01 GROUP BY department;此时 WHERE 先对每一行做判断过滤掉家电和早于 2 月的订单再进入分组参与分组的行数已经变小。第四个是HAVING 过滤分组找出订单数不少于 2 笔的部门SELECT department, COUNT(*) AS order_cnt FROM orders GROUP BY department HAVING COUNT(*) 2;注意这个COUNT(*) 2必须写在 HAVING 里写在 WHERE 里一定会报错因为 WHERE 执行时还没有 COUNT 结果可用。第五个是用ROLLUP 做层级小计先按地区汇总再在结果最后追加一行总计SELECT region, SUM(amount) AS total_amount FROM orders GROUP BY region WITH ROLLUP;MySQL 的WITH ROLLUP会给组合列附加一个 NULL 行作为小计行方便直接在报表里展示“合计”。PostgreSQL 和 SQL Server 里更多的用法是GROUPING SETS或ROLLUP(region, department)可以一次产出多种粒度的汇总不过这类语法对新手可以先有个印象。第六个是分组后取组内最早一条明细。有人会天真地写group by department再 SELECT 一个 id 或时间字段这在严格执行ONLY_FULL_GROUP_BY的数据库里直接报错。正确的做法是配合窗口函数SELECT department, id, created_at FROM ( SELECT department, id, created_at, ROW_NUMBER() OVER (PARTITION BY department ORDER BY created_at) AS rn FROM orders ) t WHERE rn 1;这里的PARTITION BY department在逻辑上等价于 GROUP BY 把数据按部门拆开区别在于它不会折叠行而是保留每行并给一个组内序号。取rn 1的那一行就是每组最早一笔订单。第七个是聚合配合条件统计统计每个部门“数码类订单金额占比”。这不是很复杂的 SQL但很能体现“分组内做条件统计”的思维SELECT department, SUM(CASE WHEN category 数码 THEN amount ELSE 0 END) AS digital_amount, SUM(amount) AS total_amount, SUM(CASE WHEN category 数码 THEN amount ELSE 0 END) / SUM(amount) AS digital_ratio FROM orders GROUP BY department;用CASE WHEN把符合条件的行映射成 1 或 0、把金额映射成原值或 0再在外面套 SUM就实现了“在组内只对部分行做聚合”的效果。这是对付“占比”“环比”“同比”这类统计需求的通用写法则。3.3 别忽略执行的中间形态临时表和索引选择GROUP BY在大多数数据库里真正执行时需要把数据按照分组键整理成一份可以逐个遍历的分组结构。MySQL 在无法通过索引直接得到有序分组时会在内存里建临时表并通过文件排序filesort来整理。当你看到EXPLAIN结果里的Using temporary; Using filesort时就要意识到这次分组很可能是全表扫完再排序的数据量大时性能会很差。一个常见优化思路是给分组键加联合索引让数据库直接按索引顺序扫描输出分组结果省掉临时表和排序。比如上面的orders表如果查询经常按(region, department)分组并按created_at做过滤可以建(region, department, created_at)这样的复合索引。理解这一步你才真正从“会写 group by”往“会写好 group by”迈进。4. 实际开发中那些坑我基本都踩过4.1 分组查询报错速查一张表对照解决我整理了一份高频报错速查表全是实际项目里会碰到的建议直接收藏。报错信息或现象原因解决办法which is not functionally dependent on columns in GROUP BY clauseSELECT 里出现了不在 GROUP BY 中的非聚合列把该列加入 GROUP BY或移动到子查询/窗口函数中Invalid use of group functionWHERE 子句里使用了 COUNT/SUM 等聚合函数把这个条件移到 HAVING 中先用 WHERE 过滤其他条件column must appear in the GROUP BY clause or be used in an aggregate functionPostgreSQL和第一条本质一致PG 报错更直白检查 SELECT 列和 GROUP BY 列的一致性汇总结果和明细对不上分组键粒度不对可能多分组了回看 GROUP BY 到底包含哪些列必要时用 COUNT(DISTINCT) 校验报表结果“随机取了一条”旧 MySQL 去掉了 ONLY_FULL_GROUP_BYSELECT 中出现了非分组列立刻改成符合规则的写法不要依赖老行为查询非常慢EXPLAIN 看到 Using temporary/filesort分组键没有索引支撑在分组键和 WHERE 常用过滤列上建联合索引这张表基本覆盖了我这些年见过的大部分 group by 翻车现场。绝大多数问题不是语法不会而是“写的时候不知道规则边界”所以把上面表格里的规则刻进脑子里比背一百条 SQL 更值。4.2 同名select引发的那些“假问题”热词里出现了很多看起来像是“select 相关报错”的东西比如select user, host from mysql.user、select the java development kit (jdk)、groups: cannot find name for group id、read/select: connection reset by peer (10054)。这些词初见挺唬人但实际上它们和 SQL 的SELECT关键字没有直接关系是命名的巧合我一开始也被误导过排查时一度以为数据库坏了。select user, host from mysql.user这句本身是 MySQL 管理员的常用查询用于查看当前 MySQL 里有哪些用户账号、允许从哪些主机连接。排查远程连不上数据库时第一步就该跑它确认你的账号 host 是不是只写了 localhost。真要远程访问需要新建user%之类的账号这里注意%是 MySQL 的通配符不表示百分号本身。select the java development kit (jdk)其实是 Gradle 启动时报的提示意思是“请选择你要用于构建的 JDK 版本”跟数据库没有半毛钱关系。常见场景是系统装了多个 JDKGradle 需要 JVM 去解析构建脚本你需要在环境变量JAVA_HOME或 Gradle 配置里指定 JDK 路径。这个报错一般出现在新克隆项目、新装环境的时候按提示去改 JDK 版本就能解决。groups: cannot find name for group id 99909997是 Linux 系统里的用户组解析问题通常出现在容器或共享存储环境下文件属组 ID 在本地 /etc/group 里找不到对应名称。排查时用getent group 99909997看组是否存在或用id确认当前用户必要时在容器里同步 /etc/group 映射。它不是 SQL 问题但如果你在写 bash 脚本去批量导数据时撞见这个报错千万别往数据库方向想要去系统层看。read/select: connection reset by peer (10054)是 Windows 下常见的网络连接错误源于Windows Sockets的WSAECONNRESET一般在客户端读取时对端强制关闭了连接。排查网络程序或数据库客户端偶尔断连时重点要看防火墙、连接池空闲超时、服务端 keepalive 配置。别看它带着select就当 SQL 语法错误这两个 select 完全是两个世界的词。这条经验真正想说的是看到一个关键词别急着套自己的知识框架先确认它到底属于哪个领域。我见过同事在一个 SQL 集群讨论里把 C 语言的select函数和数据库SELECT混在一起分析了一下午最后发现两边根本不是一件事。排查问题第一步永远是准确定位语境。4.3 分组查询慢怎么办一次真实调优记录讲一个我印象很深的案例。业务侧反馈某个按“时间渠道”汇总的报表接口越来越慢从 200ms 涨到了 15 秒。我拿EXPLAIN一看关键行是Using temporary; Using filesort表里已经有近 3000 万行历史数据。当时 SQL 长这样SELECT date(created_at) AS day, channel, count(*) FROM event_log WHERE created_at 2024-01-01 GROUP BY date(created_at), channel;优化分成两步。第一步在created_at上建了索引让 WHERE 的过滤能走索引参与分组的行从 3000 万降到 800 万左右但Using filesort还在因为分组键里用了date(created_at)这个表达式索引没法覆盖它。第二步是把查询改成新增一个day字段在建表时就把时间截断到天写入然后GROUP BY day, channel表达式索引问题消失查询耗时降到了 700ms 以内。这个案例给出一条可复用的经验分组查询慢先看是否能把 WHERE 过滤前置再看分组键是否能直接命中索引最后才考虑加缓存。很多人一上来就买内存、上中间件结果 SQL 本身还是一副全表扫描加临时表的倒霉样子加再多机器都是浪费。5. 把 group by 的思维带出 SQL同名“select”的领域辨析5.1 C 语言里的 select 函数和 SQL 完全不同热词里的c语言select解析其实说的是 Linux 网络编程里的select()系统调用。它的作用是让一个进程同时监视多个文件描述符等其中任意一个变得可读、可写或出错就返回事件程序再对就绪的描述符做处理。它和 SQL 的 SELECT 除了都叫“select”之外没有关系唯一的思想相似点是“从一堆候选中挑出符合条件的一组”一个挑的是行和列一个挑的是 IO 事件。我在团队里做过一次内部分享专门提醒大家在代码里看到select(fds, timeout)别愣住它不是数据库在执行一条 SQL而是多路复用 API。调用后返回的可读文件描述符集合常常需要配合FD_ISSET逐个检查。这类 API 在并发量稍大的时候会因为单进程能监视的描述符数量有限默认 1024而捉襟见肘Linux 下更现代的替代品是poll和epoll。理解一下这个背景以后看网络编程代码会顺畅很多。5.2 Java 里的 group byStreamAPI 的 groupingBy热词里有group()数组java显然是指 Java 8 的 Stream API 中的Collectors.groupingBy()。它的作用是把一个集合按某个属性拆成多个分组返回一个Map键是分组属性值值是组内元素列表这和 SQL 的GROUP BY聚合逻辑非常像只是运行在应用内存里。最简单的一行MapString, ListEmployee byDept list.stream() .collect(Collectors.groupingBy(Employee::getDepartment));这不仅分组还能配合下游收集器做聚合比如统计每组人数Collectors.counting()、求每组最高薪Collectors.maxBy(...)、拼接姓名Collectors.mapping(Employee::getName, Collectors.joining(,))。写法和 SQL 里的GROUP BY 聚合函数有一种奇妙的对应关系。如果你脑子里已经建好了“分组键 聚合”的模型学习这套 API 会快得多。不同点在于 Java 的 groupingBy 先得到Map再在内存里聚合性能上受内存大小约束极端情况下宁愿把聚合逻辑下沉到数据库里做也不要在应用层拉全表再分组。5.3 搜索和大数据里的“分组聚合”形态Solr group 完整代码和FPGA select map这两个热词前者是搜索引擎对结果集的字段分组后者是 FPGA 配置比特流的打包工具虽然都叫 group 或 select map但跟 SQL 的 GROUP BY 关系不大。如果你想找搜索引擎里类似分组的功能Solr 的grouptruegroup.fieldcategory参数确实可以实现“按分类分桶展示结果”Elasticsearch 里的terms aggregation也是同一个思想的实现。大数据生态里的 ClickHouse、Doris、Spark SQL本质上全都沿用GROUP BY语法执行引擎在分布式环境下会把数据按照分组键的哈希或范围分到不同节点再在各节点预聚合、最后合并结果。明白 SQL 分组逻辑的人学这些基本是零成本迁移。这一节的核心观点是分组-聚合-过滤是一套跨越数据库、编程语言、搜索引擎、大数据平台的通用的信息处理范式。你学会了 SQL 的select ... group by等于把“对一堆无序数据做归纳”的思维框架装进了脑子里。换个环境只要语法外壳变一下核心逻辑还是那一套。最后再说一点个人体会。我在业务层写 group by 时花时间最多的不是在语法而是在“把口径定义清楚”到底按什么分组、要不要去重、NULL 怎么处理、WHERE 和 HAVING 谁更早生效。这些想明白SQL 反而好写。建议你手边常备一个空临时表随便插点样例数据遇到拿不准的直接跑一下验证执行结果比翻半天文档快得多。另外分级分组时顺手看一眼EXPLAIN一旦出现Using temporary就要警惕数据量上来后的性能隐患。靠近业务、多跑多验证这个语法用顺手之后你会发现报表类需求基本都能稳稳拿下了。