在关系型数据库里，GROUP BY和聚合函数是一对必须协同工作的基础能力。GROUP BY负责把数据按某些列拆成互不重叠的组，聚合函数则负责在每个组内部做计算。如果只了解单独语法却不清楚二者约束关系，写统计查询时就会频繁踩坑。
一、GROUP BY的基本执行逻辑
当一条SQL带有GROUP BY时，数据库会先根据分组字段的值对行进行归类。例如按user_id分组，所有user_id相同的记录会被划分到同一个逻辑组里。随后，聚合函数不再面向整张表，而是面向每一个分组独立执行。这意味着分组之后，原本多行数据在结果集中被压缩为一行，这一行只能由分组字段和聚合结果构成。
很多初学者容易忽略的是，GROUP BY的执行顺序位于WHERE之后、SELECT之前。也就是说，先筛选行，再分组，最后才计算聚合。如果试图在WHERE里直接过滤聚合结果，就必须改用HAVING子句，因为WHERE阶段分组尚未发生。理解这个顺序，是避免逻辑错误的前提。
二、SELECT列的严格约束
使用GROUP BY后，SELECT后面出现的非聚合列，必须全部包含在GROUP BY子句中。以下写法在标准SQL里是非法的：
SELECT user_id, user_name, SUM(amount) FROM orders GROUP BY user_id;
上面代码中user_name没有出现在GROUP BY里，而同一user_id可能对应多个不同的user_name，数据库无法决定取哪一个，便会报错。正确写法要么把user_name也加入分组，要么放弃该列，只保留分组键与聚合值。
如果业务上确实只需要user_id和总金额，应简化为：
SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id;
这种约束保证了结果集的确定性。某些数据库如MySQL在宽松模式下可能允许非分组列出现并返回随机值，但那会埋下数据不一致的隐患，生产环境务必避免。
三、常用聚合函数行为差异
SUM、COUNT、AVG、MAX、MIN是最常用的聚合函数。它们在处理NULL时表现不同。COUNT(*)统计组内所有行，包括NULL；COUNT(列名)只统计该列非NULL的行。AVG计算时会自动忽略NULL，而不是当作0，这点和很多编程语言里的平均值逻辑不一样。
以下示例统计每个用户的订单数与平均金额：
SELECT user_id, COUNT(*) AS order_count, COUNT(discount) AS discount_filled, AVG(amount) AS avg_amount FROM orders GROUP BY user_id;
假设某用户有三笔订单，其中一笔discount为NULL，那么order_count为3，discount_filled为2，avg_amount只用两笔有效amount计算。清楚这些细节，统计报表才不会算错数。
四、HAVING筛选分组结果
当需要对分组后的聚合结果做过滤，例如只保留总金额大于1000的用户，就要用HAVING：
SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id HAVING SUM(amount) > 1000;
HAVING和WHERE的区别在于作用阶段。WHERE在分组前过滤原始行，能利用索引提升性能；HAVING在分组后过滤，通常无法使用普通索引。因此尽量把行级条件放进WHERE，只把组级条件留给HAVING。
五、多列分组与排序
GROUP BY支持多列组合，比如按地区和年份统计销售：
SELECT region, year, SUM(sales) AS total_sales FROM sales_table GROUP BY region, year ORDER BY region, total_sales DESC;
多列分组时，只有所有分组字段都相同的行才会进入同一组。ORDER BY放在最后控制输出顺序，不影响分组逻辑。合理搭配多列分组与排序，可以轻松实现复杂报表需求。
六、性能与误区总结
分组查询常成为慢SQL源头。为提升性能，应确保GROUP BY字段有索引，避免SELECT里套用复杂子查询。另一个典型误区是认为GROUP BY会改变原表数据，其实它只生成新的结果集，不对底层表做任何修改。
总的来说，掌握GROUP BY与聚合函数的配合，核心就是记住“分组后只能选分组键或聚合值”这一铁律，分清WHERE与HAVING，理解聚合函数对NULL的态度。把这些点吃透，统计类SQL就会变得稳定且可预期。