在企业的报表系统中，经常需要完成一些既包含分组汇总、又包含跨组判断的计算任务。比如统计每个地区的年度销售额，再找出销售额超过全国平均水平的地区，或者先计算每个用户的订单总数，再汇总那些高频用户的消费金额。这类需求如果只用单层SQL与聚合函数，往往难以在同一查询中既保留分组明细又完成整体比对。嵌套子查询通过将计算拆成多个逻辑阶段，可以让聚合函数在各自层面独立工作，从而写出清晰且易维护的报表查询。
一、聚合函数与GROUP BY的基础能力
聚合函数如SUM、COUNT、AVG、MAX、MIN用于对一组行计算出单个值。当配合GROUP BY使用时，数据库会先按指定列分组，再在每组内执行聚合。这是报表查询中最常见的第一步操作，能够把原始交易记录压缩成部门、月份或用户的汇总行。
需要注意的是，WHERE子句在聚合之前过滤行，而HAVING子句在聚合之后过滤分组。如果筛选条件依赖聚合结果，就必须放在HAVING中。但HAVING只能基于当前查询的分组做判断，无法直接引用“所有组算出后的整体指标”，这时就要借助子查询。
-- 统计每个部门的销售额 SELECT dept_id, SUM(amount) AS total_sales FROM orders GROUP BY dept_id;
二、嵌套子查询在报表中的典型用法
嵌套子查询是指在一个SELECT语句中嵌入另一个SELECT，内层查询先执行，将结果提供给外层使用。处理复杂报表时，常见的模式是：内层用聚合函数算出基准值（如平均值、最大值），外层再对明细分组并比较。这样每一层职责单一，不容易出错。
下面示例先通过子查询得到所有部门的平均销售额，再查出高于该平均值的部门及其总额。若不用子查询，单条语句很难在分组同时拿到“跨组平均值”去做过滤。
-- 找出销售额高于平均水平的部门
SELECT dept_id, SUM(amount) AS total_sales
FROM orders
GROUP BY dept_id
HAVING SUM(amount) > (
SELECT AVG(total)
FROM (
SELECT SUM(amount) AS total
FROM orders
GROUP BY dept_id
) AS dept_totals
);
上例中，最内层按部门汇总，中间层对汇总值求平均，外层主查询再次按部门汇总并用HAVING比较。虽然嵌套稍深，但每层只做一件事，比写成多个临时表更紧凑。
三、多阶段聚合与子查询结合实战
更复杂的报表可能要求先按天汇总，再按周求均值，最后挑出异常周。此时可以用子查询把“天汇总”固化为派生表，外层对其做周维度聚合。聚合函数分别作用于不同时间粒度，逻辑不会互相干扰。
以下代码展示如何统计每周平均日销售额，并列出平均日销售额超过百元的周。内层完成日粒度SUM，外层按周AVG，结构清楚，也方便后续加条件。
SELECT week_no, AVG(daily_sales) AS avg_daily
FROM (
SELECT WEEK(order_date) AS week_no,
order_date,
SUM(amount) AS daily_sales
FROM orders
GROUP BY WEEK(order_date), order_date
) AS daily_summary
GROUP BY week_no
HAVING AVG(daily_sales) > 100;
四、性能与可维护性权衡
嵌套子查询会引入额外的中间结果集，部分数据库优化器能将其改写为半连接或派生表合并，但过深嵌套仍可能导致执行计划变差。在报表场景通常数据量可控，优先保证逻辑清晰；若查询缓慢，可将子查询抽成物化视图或公用表表达式（CTE）辅助优化。
相比反复建临时表，合理的嵌套子查询加聚合函数能减少脚本文件数量，也让报表逻辑集中在一处。团队新人阅读时，顺着内层到外层即可理解计算顺序，降低沟通成本。
| 方案 | 优点 | 缺点 |
|---|---|---|
| 单层聚合加HAVING | 写法简单，执行较快 | 无法引用跨组整体指标 |
| 嵌套子查询加聚合 | 支持多阶段计算，逻辑清晰 | 嵌套深时优化器压力较大 |
| 临时表分步算 | 每步可单独调试 | 脚本分散，不易维护 |
五、常见误区与纠正
一个容易混淆的概念是：在WHERE里直接用聚合函数过滤。标准SQL不允许WHERE中出现SUM或AVG，因为WHERE在分组前执行。开发者有时会误写，导致语法报错。正确做法是用HAVING或在子查询中先聚合。
另外，子查询中的聚合若未取别名，外层引用可能失败。给派生表及计算列起明确名称，既符合语法，也方便后续阅读与排错。
复杂报表查询的核心，是把“算什么”和“比什么”拆到不同查询层，让聚合函数在各自层面发挥作用。
通过把嵌套子查询与聚合函数组合使用，开发者可以用纯SQL表达大多数多维度、多阶段的报表统计需求，不必依赖外部程序循环处理，既保证了数据一致性，也提升了查询语句的表达力。