在编写SQL统计查询时，一个常见的疑问是：为什么GROUP BY子句会限制SELECT列表中的非聚合字段？例如想要同时查询部门编号、平均薪资和员工姓名，直觉上写出的SQL往往无法执行。要回答这个问题，需要先理解聚合操作对结果集行粒度的改变。
一、GROUP BY的字段限制来自行粒度收缩
GROUP BY的核心职责是对数据进行分组，并把每个组折叠成一行。假设有一张employee表，包含emp_id、emp_name、dept_id和salary四个字段。如果执行按部门统计平均薪资的查询，SQL可以写成下面这样：
SELECT dept_id,
AVG(salary) AS avg_salary
FROM employee
GROUP BY dept_id;
这条语句的结果每个dept_id只出现一次，因为分组后每一行代表的是一个部门整体，而不是原来的某个员工。此时如果想把emp_name也放进SELECT列表，SQL标准会认为这是不合法的，原因在于一个部门里有多个员工姓名，分组后的单行无法确定应该展示哪一个姓名。即使是MySQL在关闭ONLY_FULL_GROUP_BY模式时能够执行这类语句，返回的姓名也往往只是存储顺序中的某个值，并不具备业务含义，甚至可能造成误导。
从逻辑执行顺序看，标准SQL先经过FROM和WHERE得到明细行，然后执行GROUP BY把明细行合并，之后才轮到SELECT和ORDER BY。也就是说，到达SELECT阶段时，原始字段已经不再以明细行的形式存在。引擎只能读取两类信息：一类是参与分组的字段，例如dept_id；另一类是基于整个分组计算出来的聚合值，例如AVG(salary)。这就是聚合查询无法返回明细字段的根本原因。
二、窗口函数在保留明细行的同时完成聚合
窗口函数提供了另一种计算思路。它并不会把多行合并成一行，而是在当前结果集的每一行上，根据OVER子句定义的计算范围进行聚合。以同样的部门平均薪资为例，查询可以写成：
SELECT emp_id,
emp_name,
dept_id,
salary,
AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg_salary
FROM employee;
这条查询不会返回所有员工明细，同时每一行都携带了该员工所在部门的平均薪资。PARTITION BY dept_id的作用类似于分组，但它只用于划定窗口边界，不会改变结果集的行数。引擎在计算dept_avg_salary时，会把相同dept_id的行视作一个窗口，在这个窗口内求平均值，然后把结果写回到窗口中的每一行。因此emp_id、emp_name和salary这些明细字段都可以正常显示。
窗口函数还可以配合ORDER BY实现累计统计和组内排名。例如RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC)可以给每个部门的员工按薪资从高到低排名，SUM(salary) OVER (PARTITION BY dept_id ORDER BY emp_id)则可以计算按员工编号排序后的累计薪资。这些能力是普通GROUP BY难以直接完成的，因为分组查询只有最终一行的结果，无法保留排序过程中的中间状态。
下面是一个同时展示部门平均薪资与组内排名的示例：
SELECT emp_id,
emp_name,
dept_id,
salary,
AVG(salary) OVER (PARTITION BY dept_id) AS dept_avg_salary,
RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS salary_rank
FROM employee;
从结果的行数、可引用字段和执行阶段三个方面，可以更清楚地看出窗口函数与GROUP BY的区别。第一，GROUP BY返回的行数通常等于分组数量，窗口函数返回的行数则等于输入明细行数。第二，GROUP BY只能引用分组键和聚合函数，窗口函数查询可以引用全部原始字段。第三，GROUP BY发生在SELECT之前的聚合阶段，窗口函数则是在SELECT列表中进行计算，逻辑上处于结果集已经形成之后。
三、用GROUP BY回连明细表也能实现类似效果
并不是所有需要保留明细字段的场景都必须使用窗口函数。如果聚合逻辑比较简单，另一种常见做法是先使用GROUP BY得到分组统计结果，再通过JOIN回连到原始明细表。这样明细行依然完整，聚合值则来自派生表或公共表表达式。示例如下：
WITH dept_avg AS (
SELECT dept_id,
AVG(salary) AS avg_salary
FROM employee
GROUP BY dept_id
)
SELECT e.emp_id,
e.emp_name,
e.dept_id,
e.salary,
d.avg_salary
FROM employee e
JOIN dept_avg d
ON e.dept_id = d.dept_id;
这种写法的执行计划通常包含两次扫描或一次扫描加哈希匹配，性能取决于表大小和索引情况。相比之下，窗口函数只需要一次扫描数据，但可能需要在内部进行排序和窗口聚合操作。对于大型表，窗口函数不一定总是更快，尤其是当分区键和排序键无法利用现有索引时，数据库可能需要在内存或磁盘上进行额外排序。
在实际项目中，若需求只是展示每行明细并附带一个分组聚合值，窗口函数通常更直观。如果聚合结果需要被多次复用，或者聚合计算非常复杂，先物化GROUP BY结果再用JOIN回连会更容易维护，也能避免在多个窗口函数中重复计算相同聚合。不同数据库对窗口函数的优化程度不同，建议通过执行计划观察是否存在不必要的排序节点。
四、常见误解与调试注意事项
一个典型的误解是把窗口函数当作GROUP BY的完全替代品。窗口函数虽然能保留明细，但它不会减少结果集行数，也不能在WHERE条件中直接过滤聚合后的排名结果。例如想取出每个部门薪资最高的员工，下面这种写法会报错：
SELECT emp_id,
emp_name,
dept_id,
salary,
RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS salary_rank
FROM employee
WHERE salary_rank = 1;
原因在于窗口函数的计算阶段位于WHERE之后，WHERE执行时salary_rank还不存在。正确的做法是使用子查询或公共表表达式，先计算窗口结果，再在外层进行过滤：
SELECT *
FROM (
SELECT emp_id,
emp_name,
dept_id,
salary,
RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS salary_rank
FROM employee
) t
WHERE salary_rank = 1;
另一个常见误区是认为只要数据库不报错，GROUP BY查询中放明细字段就没有问题。部分数据库在兼容模式下可能允许这种语法，但这会带来结果不确定的风险。建议始终开启ONLY_FULL_GROUP_BY或等效的严格模式，让数据库帮助发现潜在的错误逻辑。在MySQL 5.7及以上版本中，该模式默认开启；在PostgreSQL、SQL Server和Oracle中，SQL标准行为会直接阻止这类非法引用。
调试窗口函数查询时，可以关注执行计划中的WindowAgg或Sort节点。如果分区键和排序键上建有合适的复合索引，例如(dept_id, salary)，某些数据库可以避免额外排序。对于只需要聚合值而不需要保留原始行顺序的场景，尽量使用PARTITION BY而不是不必要的ORDER BY，因为窗口内的排序会带来额外成本。