在关系型数据库的日常使用中，PostgreSQL凭借丰富的聚合能力与灵活的分组语法，成为复杂报表统计场景下的优选方案。聚合函数用于将多行数据计算为单个结果，而GROUP BY则决定了数据按照哪些列进行归并。掌握二者在高级场景下的配合方式，可以避免大量冗余代码与重复扫描，让查询既简洁又高效。
多维汇总的GROUPING SETS与CUBE用法
传统GROUP BY只能按照固定的一组列进行分组，如果需要同时按照部门、按照城市、以及整体总计分别统计，往往要写多条SQL再做UNION ALL。PostgreSQL提供的GROUPING SETS允许在一条语句中声明多个分组集合，数据库会对数据进行一次扫描，分别按不同维度输出聚合结果。这种方式不仅减少了IO次数，也让结果集结构更统一，便于上层应用直接消费。
举例来说，假设有一张销售表sales，包含region（地区）、category（品类）和amount（金额）。如果我们既想看各地区各品类的汇总，也想看仅按地区汇总，以及仅按品类汇总，就可以使用GROUPING SETS。下面的代码展示了具体写法，其中每个括号内代表一个分组维度组合，空括号表示全局总计。
SELECT
region,
category,
SUM(amount) AS total_amount
FROM sales
GROUP BY GROUPING SETS (
(region, category),
(region),
(category),
()
);
除了GROUPING SETS，PostgreSQL还支持CUBE和ROLLUP。CUBE会生成给定列的所有可能组合的分组，适合需要全方位交叉分析的场合；ROLLUP则按照列的顺序生成层级汇总，常用于带有自然层级关系的统计，比如年、月、日的下钻汇总。需要注意的是，维度列过多时CUBE会产生指数级的分组数量，因此要结合业务必要性来选用，避免不必要的计算开销。
FILTER子句实现条件聚合
在早期SQL写法中，如果要在同一个分组里统计不同条件的数据，通常只能写多个CASE WHEN把不符合条件的值转为NULL再交给聚合函数处理。这种写法不仅冗长，而且当条件变多时极难维护。PostgreSQL为聚合函数引入了FILTER子句，可以直接在聚合调用时声明过滤条件，使语义一目了然，也减少了嵌套层级。
以下示例在按部门分组的同时，分别统计男性与女性的员工数量。使用FILTER后，每个SUM或COUNT只处理满足条件的数据行，逻辑与性能都优于CASE WHEN方案。对于大型表，FILTER往往能被规划器更好地优化，因为它明确限定了输入集合。
SELECT
department_id,
COUNT(*) FILTER (WHERE gender = 'M') AS male_count,
COUNT(*) FILTER (WHERE gender = 'F') AS female_count,
AVG(salary) FILTER (WHERE salary > 5000) AS high_salary_avg
FROM employees
GROUP BY department_id;
从执行计划角度看，FILTER子句并不会改变聚合本身的一次性分组扫描，它只是在聚合内部做行级筛选，因此不会产生额外的子查询或临时表。在报表查询中，将原先分散在多个CTE里的条件统计合并到带FILTER的单一聚合查询里，往往能让SQL缩短一半以上，同时数据库优化器也更容易推算出准确的基数估计。
聚合与窗口函数配合避免自连接
很多开发者在算完分组聚合后，还需要把聚合结果放回原明细行上做对比，例如标记出每个部门中高于平均工资的员工。 naive的做法是先GROUP BY算出部门平均，再把这个中间表通过部门ID连接回原表。这种自连接不仅写起来麻烦，而且在数据量大时会产生额外的哈希连接开销。
PostgreSQL的窗口函数可以在保留原行的基础上，通过PARTITION BY模拟分组并计算聚合，无需任何连接操作。下面的例子用AVG() OVER (PARTITION BY department_id)直接得到部门平均，并与当前行salary比较，整个查询只扫描一次employees表。这种方式既直观又高效，是高级SQL编写的必备技巧。
SELECT
employee_id,
department_id,
salary,
AVG(salary) OVER (PARTITION BY department_id) AS dept_avg,
CASE
WHEN salary > AVG(salary) OVER (PARTITION BY department_id)
THEN 'above'
ELSE 'below'
END AS compare_flag
FROM employees;
需要区分的是，窗口函数里的聚合不会压缩行数，它只是为每一行附加一个聚合值；而GROUP BY聚合会把多行变一行。二者在语义上互补：当既要明细又要分组指标时，优先用窗口函数；当只需要汇总结果时，仍应使用GROUP BY。在实际复杂报表中，经常会出现先GROUP BY做粗粒度汇总，再在外层用窗口函数做占比计算的混合写法，这种组合能最大化利用PostgreSQL的执行引擎特性。
自定义聚合与有序聚合扩展
除了内置的SUM、COUNT、AVG等，PostgreSQL允许通过CREATE AGGREGATE定义自己的聚合函数，用于处理特殊业务计算，比如拼接去重字符串、计算中位数等。配合ORDER BY在聚合内部指定排序，还能实现诸如按时间顺序拼接日志之类的有序聚合，这是很多其他数据库不具备的灵活度。
例如，使用内置的string_agg配合ORDER BY，可以按指定顺序把同一组的名字连成逗号分隔的串，而不依赖外层排序。对于更复杂的情况，比如需要在一个聚合里同时维护多个状态变量，可以基于C语言扩展或PL/pgSQL编写状态转移函数与最终函数，注册成聚合。虽然自定义聚合开发成本较高，但在高频复用的统计口径中，它能把业务规则固化到数据库层，减少应用端逻辑。
SELECT
department_id,
string_agg(employee_name, ',' ORDER BY hire_date) AS joined_names
FROM employees
GROUP BY department_id;
在运用这些高级特性时，也应注意统计信息的维护。GROUPING SETS和自定义聚合都可能让规划器难以估算中间结果规模，因此定期执行ANALYZE、在关键列上建立合适索引，仍是保障性能的基础。只有把语法能力与实践调优结合，PostgreSQL的聚合与分组体系才能发挥出真正价值。
PostgreSQLaggregate_functionGROUP_BY修改时间：2026-08-18 23:18:35