企业官网建设流程全解析

在使用SQL的路上，SELECT和GROUP BY大概是最让人又爱又恨的两个关键词。有人天天用，却始终没搞懂GROUP BY到底在做什么；有人一写分组查询就报错，被“SELECT列表不在GROUP BY子句中”折腾得头皮发麻。如果你也卡在这些地方，那我这篇总结值得你花十分钟看完。我会从一条完整的查询语句出发，把SELECT和GROUP BY的执行逻辑、多字段分组的写法、HAVING和WHERE的取舍、常见报错和隐蔽坑一个个拆开，并用大量实际可跑的示例给你演示。无论你是刚学SQL的初学者，还是写了好几年业务查询的老手，都能从这里找到能直接上手的思路。

1. 理解SELECT与GROUP BY的本质：查询的执行顺序说了算

1.1 SELECT不光是取数，它是整个查询的“组装车间”

很多人在初学SQL时，习惯把SELECT当成一条查询的起点：“SELECT 就是我要查出哪些列”。但如果只看SELECT，你就会一直不理解GROUP BY、HAVING、ORDER BY在它前后到底怎么配合。这里最大的误区在于：SQL的书写顺序和它的实际执行顺序完全是两回事。

SQL语句的逻辑执行顺序，其实是这样的：先确定数据从哪张表来（FROM），然后过滤掉不需要的行（WHERE），再把剩下的行按某个字段“分桶”（GROUP BY），接着对分好组的桶做条件筛选（HAVING），然后才轮到SELECT去组装最终要返回的列，最后再做排序（ORDER BY）和分页（LIMIT）。

换句话说，SELECT在整条语句里执行得比你想象中晚得多。它是在数据已经被过滤、分组、聚合完之后，才来决定“哪些列要展示出来、聚合结果叫什么名字”。所以当你看到一条复杂的SQL时，别急着看SELECT写的是什么，先看FROM和WHERE，再去推理GROUP BY之后的结果集长什么样，最后才明白SELECT为什么能这么写。

这个顺序的认知特别重要。比如你会经常看到“SELECT中出现的字段必须出现在GROUP BY里”的报错，原因就是分组后每个桶里只剩下分组字段和聚合函数的结果，其他原始列的取值已经不是唯一的了。如果硬要在SELECT里取一个没被分组的列，数据库根本不知道该拿哪一条记录的值给你。

1.2 GROUP BY不是排序，它的核心动作是“分桶”

GROUP BY这个名字容易让人产生一种误解，以为它是用来“分组排序”的。实际上，它做的事情是把表里的行按照一个或多个字段的值进行分类，相同值的行被放进同一个桶，然后对每个桶分别进行聚合统计。你可以把GROUP BY想象成洗菜时候的“分筐”：按品种把菜放进不同筐，然后你才能分别称重、计价、统计数量。

一个非常典型的场景是：表里有全国各个城市的订单记录，现在你想知道每个城市的订单总数。如果没有GROUP BY，你只能把全表数据拉到应用里，自己写循环维护一个城市到数量的映射，这就是把数据库该干的活拿到代码里干了。而有了GROUP BY，你只需要这样写：

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

数据库会把所有相同city值的订单行放进同一个“城市桶”，然后对每个桶调用COUNT(*)数一数有多少行，最终返回每个城市对应的一个统计结果。注意，这里的结果集里每个城市只会出现一次，因为每个桶已经合并成了一条输出记录。

理解了“分桶”之后，你就会明白GROUP BY为什么天然会去重。这也解释了很多人拿GROUP BY来去重的做法，虽然能用，但有些隐患，后面我会专门讲。

2. GROUP BY的完整实操：从单字段分组到多字段分组，再到HAVING

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

在日常业务中，单字段分组是最常见的用法。比如按部门统计人数、按商品分类统计库存总量、按用户状态统计数量等。这里我拿一个经典的员工表来演示。

假设有一张员工表employees，字段包括dept（部门）、name（姓名）、salary（薪资）。你想统计每个部门的人数、平均薪资、最高薪资和最低薪资，SQL可以这样写：

SELECT dept, COUNT(*) AS total_people, AVG(salary) AS avg_salary, MAX(salary) AS max_salary, MIN(salary) AS min_salary FROM employees GROUP BY dept;

这里COUNT、AVG、MAX、MIN都是聚合函数，它们只对每个分组（部门）内的行起作用。你会看到每个部门输出一行统计结果。这在实际报表中非常实用，一次查询就能拿到多个汇总指标。

这里我要说一个容易被忽略的点：加了GROUP BY之后，SELECT里只能出现分组字段和聚合函数，否则数据库很可能报错，这是很多新手的第一个坎。至于为什么，我放到3.3节专门讲。

2.2 多字段分组：GROUP BY多个字段的正确姿势

Group By后面可以跟多个字段，这是很多场景下必须用到的能力。比如你不仅要看每个部门，还想进一步细化到部门下的每个职位，那就需要同时按dept和job两个字段分组。写法非常简单，用逗号分隔即可：

SELECT dept, job, COUNT(*) AS people_cnt FROM employees GROUP BY dept, job;

这里的分组逻辑是：先把dept相同的行归到一起，再在同一个部门内部，按job继续拆成更小的子集。你可以把它理解成先按部门分筐，再在每个部门筐里按职位分成小格。只有当两个字段的值都相同的时候，这些行才被放到同一个最终分组里。

多字段分组经常用在时间维度上。比如我想按年和月统计销售额，可以用YEAR(order_date)和MONTH(order_date)作为分组字段：

SELECT YEAR(created_at) AS y, MONTH(created_at) AS m, SUM(amount) AS monthly_sales FROM orders GROUP BY YEAR(created_at), MONTH(created_at) ORDER BY y, m;

需要注意，虽然SELECT里的别名可以用于ORDER BY，但GROUP BY后面一般建议直接写原表达式，而不是别名。虽然很多数据库允许在GROUP BY中使用别名，比如MySQL就支持GROUP BY y, m，但SQL标准并没有强制要求所有数据库都同意。为了可移植性和可读性，我个人的习惯是GROUP BY里写实际表达式，ORDER BY里再用别名。

多字段分组还有一个隐藏的坑：字段顺序会影响分组的效率，但不会影响最终的结果集内容。比如GROUP BY dept, job和GROUP BY job, dept返回的行内容是一样的，只是内部聚合的路径不同，对索引的利用也可能不同。这点我会在第三章讲索引时再展开。

2.3 HAVING与WHERE的分工：过滤时机决定结果

很多人分不清WHERE和HAVING，其实它们的核心区别就一句话：WHERE在分组之前过滤原始行，HAVING在分组之后过滤分组结果。这个时机的差异直接影响查询结果。

举个例子。还是订单表，我想统计每个客户的总消费额，但只关心那些订单金额超过100元的订单（这里假设订单表有订单金额字段amount）。如果你用WHERE先过滤掉金额小于等于100的订单，再按客户分组求和，那么统计出来的就是“高金额订单带来的客户消费额”。SQL是这样：

SELECT customer_id, SUM(amount) AS total FROM orders WHERE amount > 100 GROUP BY customer_id;

但如果你改用在分组后用HAVING过滤，比如只输出消费总额超过1000元的客户，那写法就是：

SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING SUM(amount) > 1000;

这里要注意，HAVING里可以直接写聚合函数SUM(amount) > 1000，但WHERE里不可以，因为WHERE执行时分组还没发生，聚合函数根本没法计算。

还有一个小技巧：如果你既需要过滤原始行，又需要过滤分组后的结果，可以两者一起用。比如先只统计状态为“已完成”的订单（WHERE），再输出总额超过1000的客户（HAVING）：

SELECT customer_id, SUM(amount) AS total FROM orders WHERE status = 'completed' GROUP BY customer_id HAVING SUM(amount) > 1000;

我在实际项目里见过不少同事为了让“总额大于1000”生效，把客户ID全部拉出来再在代码里算一遍，反而增加了网络开销。其实HAVING就是数据库原生的分组后过滤手段，能一条SQL解决的事，就没必要在应用层二次处理。

3. 进阶细节：聚合函数的使用边界、索引优化与常见报错

3.1 聚合函数与GROUP BY搭配时容易忽视的细节

COUNT、SUM、AVG、MAX、MIN这几个聚合函数是分组查询的标配。但在实际使用中，有几个细节很容易被忽略。

第一个是COUNT(*)和COUNT(某个字段)的区别。COUNT(*)数的是分组内的所有行，即使整行所有字段都是NULL，它也会计入；而COUNT(列名)只统计该列非NULL的行数。如果你想知道某个分组里有多少条记录有填写手机号，就写COUNT(phone)；如果你只想知道有多少条记录，用COUNT(*)就行。这两者的结果很可能不一样，这一点在统计缺失率的时候非常有用。

第二个是SUM和AVG会自动忽略NULL值，也就是说，某个组内如果某行的字段是NULL，它不参与求和和求平均，但这并不代表你不用处理业务上的空值。比如订单表中，退款金额字段refund_amount可能对未退款订单是NULL，直接AVG(refund_amount)只会对有退款的订单求平均，这显然不是你想要的“所有订单的平均退款金额”。这时候你需要用COALESCE(refund_amount, 0)把NULL转成0再聚合：

SELECT customer_id, AVG(COALESCE(refund_amount, 0)) AS avg_refund FROM orders GROUP BY customer_id;

这个坑我踩过不止一次，输出报表时发现平均值低得离谱，怀疑是SQL写错了，其实是NULL被忽略导致的。

第三个是MAX和MIN对文本类型也可以生效，数据库按字典序比较文本。但要注意，这个行为在不同数据库或者不同排序规则下可能不一致，像MySQL里如果字段是utf8mb4的默认排序规则，中文排序结果可能不是你预期中的拼音顺序，千万小心。

3.2 索引如何影响GROUP BY：分组不一定要排序

很多人不知道，GROUP BY背后的一个主要成本是“分组”本身。数据库想要把相同值的行放到一起，常见做法是排序或哈希。如果查询优化器选择了排序，并且分组字段正好有可用的索引，那么优化器就能直接利用索引的有序性，按顺序扫描数据，遇到相同值就归为一个组，避免额外的排序操作。

这就意味着，如果你的分组字段上建有索引，查询效率往往能提升一大截。特别是对高频统计查询，这个提升非常明显。举个例子，如果经常要按订单状态分组统计数量，那么给status字段建一个索引通常是不错的选择。但要注意，多字段分组时，索引最好遵循最左前缀原则。比如你建立了(dept, job)联合索引，那么GROUP BY dept和GROUP BY dept, job都能利用到这个索引，但GROUP BY job, dept则不一定能高效利用，因为字段顺序和索引顺序不一致。

我见过一个电商后端的真实案例：订单表的查询经常按status和pay_type两个字段分组统计，但优化器一直走全表扫描，后来给(status, pay_type)建了联合索引，查询时间从800多毫秒降到了80毫秒。注意，建索引不是越多越好，你得先看哪些分组查询是真正的热点，再针对性地建。

另外，当你用EXPLAIN查看执行计划时，如果看到Using temporary; Using filesort，说明GROUP BY可能触发了临时表和文件排序。如果这个SQL是高频查询，就要想想能不能靠索引消除它。当然，不是所有文件排序都不好，小数据量时无所谓，但大数据量高并发下还是值得优化的。

3.3 为什么SELECT的列必须出现在GROUP BY里

这个问题几乎每个学SQL的人都问过：我明明只是想查dept和name，为什么GROUP BY dept就不让查name？答案说起来很简单：当你只按dept分组后，每个部门桶里有多个员工，如果SELECT里出现了name，那这行name到底取哪一个？是没有意义的。

举一个更直观的例子：

SELECT dept, name FROM employees GROUP BY dept;

假设“销售部”有张三、李四、王五三个人，那么查询结果里销售部那一行，到底应该显示张三、李四还是王五？数据库没法替你决定，所以它直接报错。如果你确实想看到分组内的多个姓名，那就要用聚合函数，比如GROUP_CONCAT(name)（MySQL）或者STRING_AGG(name)（PostgreSQL、SQL Server），这些函数能把多个值拼成一个字符串返回。

不过，不同数据库对这个问题处理方式并不一致。MySQL默认开启了ONLY_FULL_GROUP_BY模式，会严格报错；而在某些模式下，MySQL允许查询未分组的非聚合列，此时它随机选一条记录的值，结果不可预测。这可能让你在开发环境跑得好好的，换到另一个环境就报错了。最稳妥的写法永远是：SELECT中要么是分组字段，要么是聚合函数，不要贪图省事去省略GROUP BY里的字段。

4. 实战中踩过的坑：问题排查与解决速查

4.1 ONLY_FULL_GROUP_BY报错：MySQL最常见的分组烦恼

很多刚接触MySQL的人一写分组查询就报错：Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column ... which is not functionally dependent on columns in GROUP BY clause。这串报错看着吓人，其实原因就是上面说的SELECT里出现了不在GROUP BY中的普通列。

如果你确认业务上某个字段和分组字段是函数依赖关系，比如按主键id分组，同时查询name，因为主键唯一，name必然随之唯一，这其实是合理的查询。但MySQL默认的ONLY_FULL_GROUP_BY模式对“函数依赖”的判断在旧版本里不够友好，导致这种本来就没错的SQL也会被拦截。情况不同处理方式也不同：

• 如果是业务逻辑本来就该按多个字段分组，那就把缺少的字段补到GROUP BY里面。
• 如果是想展示组内某个具体值，可以用MAX、MIN或ANY_VALUE()将就一下，但前提是你确定这个值在组内是一致的。
• 如果你就是想把所有行的值拉出来，考虑用GROUP_CONCAT。

我不太建议为了绕过报错而直接关闭ONLY_FULL_GROUP_BY，因为那条你临时绕过去的SQL很可能埋着一个本不该有的逻辑错误。关掉它是治标不治本，正确理解分组语义才是长久之计。

4.2 GROUP BY NULL的隐藏陷阱

这个坑很隐蔽。你可能写了这样一句：

SELECT dept, COUNT(*) FROM employees GROUP BY dept;

看起来没毛病，但如果你表里有一些部门的dept字段是NULL，数据库会把所有dept为NULL的行也当作一个分组，输出一行NULL, 数量。这个行为在SQL标准里是默认的：NULL也参与分组，所有的NULL值被归为同一组。

在很多业务报表中，这行NULL分组经常让人困惑。比如你想统计每个部门的人数，结果看到一行“空值部门”，还以为数据库坏了。实际上这是正常的，你需要决定是自己接受它，还是在查询中显式处理。比如你可以这样写，把NULL替换成“未分配”：

SELECT COALESCE(dept, '未分配') AS dept, COUNT(*) FROM employees GROUP BY dept;

或者反过来，只想统计有部门的人，就直接在WHERE里加dept IS NOT NULL。很多人在GROUP BY问题排查时卡了半天，最后发现是NULL在捣乱。

4.3 用GROUP BY去重的隐患，以及和DISTINCT的对比

互联网上很多“SQL去重”的文章会教你用GROUP BY来去重，因为分组后每组只返回一行。这种写法确实可行，比如：

SELECT name, age FROM users GROUP BY name, age;

这确实能拿到不重复的 “name+age” 组合。但有两个隐患：第一，如果你只是想要去重后的完整行，用SELECT DISTINCT语义更清晰，而且某些数据库中DISTINCT的执行计划可能更优；第二，如果你在GROUP BY中只写部分字段，SELECT里又带出别的字段，大概率会触发4.1中说的报错。更糟糕的是，在一些宽容模式下可能不报错，但返回的随机值会严重误导业务。

我的建议是：单纯去重用DISTINCT，统计聚合才用GROUP BY。两者混用会给自己和后来维护代码的人留下理解成本。

4.4 那些所有搜索结果看起来像SQL，但并不是同一个“SELECT”的坑

看到热搜词里出现了一大堆带着“select”字样的短语，比如select user,host from mysql.user、read/select: connection reset by peer、select the java development kit (jdk) you want gradle to use等等，我发现很多人其实是被不同类型的“select”搅混了。

先说select user,host from mysql.user。这个确实是SQL，它是MySQL用户权限管理中的经典查询，用来查看MySQL账号和允许连接的主机名。它和普通业务查询没有任何区别，只是操作的库表是系统自带的mysql.user。要注意的是，普通业务账号未必有权限查询这张表，如果报错权限不足，需要管理员账号执行。这个查询常用于排查“某个用户到底能不能从某个IP访问”之类的权限问题。

再看read/select: connection reset by peer。这是网络层或者IO的错误信息，和SQL里的SELECT没有关系，通常出现在TCP连接被对端重置时。比如你从应用服务器连接数据库，中间经过防火墙、负载均衡，某个环节主动断开连接，客户端就会报这个错。排查方向应该在连接池配置、网络稳定性、数据库空闲连接超时设置上，而不是去看SQL语法。

还有select the java development kit (jdk) you want gradle to use when building...。这是在运行Gradle构建任务时的交互提示，意思是让你选择一个JDK版本。它压根不是查询语句，只是命令输出里恰好包含了“select”这个词。如果你搜索时看到这种标题，要能分辨出它属于特定工具的执行界面，别被“select”带偏。

最后提一句热词里的groups: cannot find name for group id 99909997。这其实是Linux系统在解析用户组时出现的报错，意思是某个文件的所有者组ID在系统组文件中找不到对应的组名。它跟SQL的GROUP BY没有半点关系，但因为在日志里经常和数据库进程放一起，新手容易混淆。遇到这种问题，通常是在迁移数据或者解压文件时，系统用户组ID不一致导致的，用ls -n查看数字ID，再找对应的组名排查即可。

这些“伪SQL”坑提醒我们一件事：任何一个具备专业技能的人，都要具备“识别报错来源”的嗅觉。判断问题属于数据库、网络、操作系统还是构建工具，可以少走很多弯路。我在实际工作中，通常先看报错出现的位置，再确定环境，最后才去怀疑SQL语句本身。

写在最后的一点经验分享

RECENTLY rewritten. Me again. 我几乎每个星期都会帮同事看分组查询的问题，大部分都不是SQL不会写，而是没理解分组后的数据形态。记住一个心得：写带GROUP BY的SQL时，先用脑子把“分完桶之后每个桶长什么样”画出来，再决定SELECT里放什么。只要你对每个桶的形态有清晰认知，很多报错根本不会出现。

另外，我在查线上慢查询时，从来不会只看有没有索引，而是先看这条SQL是不是真的需要“分桶”，能不能先用WHERE把数据范围缩小。很多时候，分组前的过滤数据量减少90%，比什么优化都管用。GROUP BY本身不慢，慢的是你让它在海量无关数据上做无用功。

如果你正在学SQL，建议自己建一张几万行的表，反复用单字段分组、多字段分组、HAVING过滤、NULL字段分组等组合练几遍，把执行结果和自己的预判对照起来。踩几次坑之后，你会发现自己对SQL的理解会明显上一个台阶。