在SQL的实际业务场景中，经常需要同时关联多张表，再对关联后的结果做聚合计算，比如统计每个用户的订单总金额、每个部门的员工平均绩效等。但很多开发者会发现，直接关联后做聚合得到的结果往往是错误的，核心原因就是出现了数据膨胀。
多表关联聚合为什么会出现数据膨胀
数据膨胀的本质是关联操作导致数据行数被放大，进而影响聚合结果。举个常见的业务例子：有两张表，一张是用户表user_info，记录用户基础信息，一张是订单表order_info，记录用户的订单明细，还有一张是用户积分变更表point_log，记录用户的积分变动记录。
现在需要统计每个用户的订单总金额，同时统计每个用户的积分总变动值。如果直接用内连接关联三张表，再做聚合，就会出现问题。
先来看三张表的示例结构：
-- 用户表
CREATE TABLE user_info (
user_id INT PRIMARY KEY,
user_name VARCHAR(50)
);
-- 订单表
CREATE TABLE order_info (
order_id INT PRIMARY KEY,
user_id INT,
order_amount DECIMAL(10,2)
);
-- 积分变更表
CREATE TABLE point_log (
log_id INT PRIMARY KEY,
user_id INT,
point_change INT
);
插入一些测试数据：
INSERT INTO user_info VALUES (1, '张三'), (2, '李四'); INSERT INTO order_info VALUES (1, 1, 100.00), (2, 1, 200.00), (3, 2, 150.00); INSERT INTO point_log VALUES (1, 1, 50), (2, 1, 30), (3, 2, 20);
如果直接关联三张表做聚合，SQL语句如下：
SELECT
u.user_id,
u.user_name,
SUM(o.order_amount) AS total_order_amount,
SUM(p.point_change) AS total_point_change
FROM user_info u
INNER JOIN order_info o ON u.user_id = o.user_id
INNER JOIN point_log p ON u.user_id = p.user_id
GROUP BY u.user_id, u.user_name;
执行这段SQL后，用户张三的订单总金额会显示为(100+200)*2=600，积分总变动会显示为(50+30)*2=160，结果明显错误。这是因为用户张三有2个订单、2条积分记录，关联后会产生2*2=4行数据，聚合时就会把重复的行计算进去，这就是典型的数据膨胀问题。
使用窗口函数避免数据膨胀的实现思路
窗口函数的特点是不会对数据进行分组聚合后减少行数，而是在原有数据行的基础上，新增聚合计算的结果列，这样就可以先分别计算每张表的聚合值，再关联到一起，避免多表关联时的行数放大问题。
具体的实现步骤可以分为三步：
- 第一步，对订单表按用户维度做聚合，用窗口函数计算每个用户的订单总金额，同时保留用户ID作为关联键
- 第二步，对积分变更表按用户维度做聚合，同样用窗口函数计算每个用户的积分总变动值，保留用户ID作为关联键
- 第三步，将用户表分别和上面两个聚合结果做关联，因为两个聚合结果每个用户只有一行数据，关联后不会产生行数放大，聚合结果也不会出错
窗口函数方案的具体代码示例
首先用窗口函数计算订单表的用户订单总金额：
SELECT
user_id,
SUM(order_amount) OVER (PARTITION BY user_id) AS total_order_amount
FROM order_info
这个查询的结果中，每个订单行都会带上对应用户的订单总金额，同一个用户的所有行的total_order_amount值是相同的，我们可以先对这个结果去重，每个用户只保留一行，作为订单聚合的中间表。
同理，计算积分变更表的用户积分总变动值：
SELECT
user_id,
SUM(point_change) OVER (PARTITION BY user_id) AS total_point_change
FROM point_log
同样对这个中间结果去重，每个用户保留一行。最后将用户表和这两个去重后的中间表关联：
WITH order_agg AS (
SELECT DISTINCT
user_id,
SUM(order_amount) OVER (PARTITION BY user_id) AS total_order_amount
FROM order_info
),
point_agg AS (
SELECT DISTINCT
user_id,
SUM(point_change) OVER (PARTITION BY user_id) AS total_point_change
FROM point_log
)
SELECT
u.user_id,
u.user_name,
COALESCE(o.total_order_amount, 0) AS total_order_amount,
COALESCE(p.total_point_change, 0) AS total_point_change
FROM user_info u
LEFT JOIN order_agg o ON u.user_id = o.user_id
LEFT JOIN point_agg p ON u.user_id = p.user_id;
执行这段SQL后，用户张三的订单总金额是300.00，积分总变动是80，结果完全符合预期。这里用LEFT JOIN是为了保证即使用户没有订单或者积分记录，也能正常显示用户信息，没有对应记录的话聚合值显示为0。
两种方案对比
我们可以通过表格对比传统直接关联聚合和窗口函数方案的差异：
| 方案 | 实现逻辑 | 数据行数变化 | 聚合结果准确性 | 适用场景 |
|---|---|---|---|---|
| 直接关联后聚合 | 多表直接关联后执行GROUP BY聚合 | 关联时行数被放大，聚合后行数减少 | 容易出现数据膨胀，结果错误 | 仅关联单张表做聚合的场景 |
| 窗口函数方案 | 先分别计算各表聚合值，再关联 | 中间结果每个维度一行，关联后行数无放大 | 不会出现数据膨胀，结果准确 | 多表关联后需要做聚合计算的场景 |
注意事项
使用窗口函数方案时，需要注意几个细节：
- 窗口函数计算聚合值后，一定要对中间结果做去重处理，否则关联时还是可能出现行数放大，比如订单表同一个用户有多行，不去重的话关联后还是会有多行
- 如果关联的表中有重复的聚合维度值，需要先确认聚合逻辑，避免去重时丢失数据
- 窗口函数的PARTITION BY字段要和后续关联的字段一致，否则聚合值对应不上
除了多表关联聚合的场景，窗口函数还可以用在很多不需要减少行数的聚合计算场景中，比如计算每个部门内员工的薪资排名、每个用户相邻订单的时间间隔等，合理使用窗口函数可以简化很多复杂的SQL逻辑，提升查询的可读性和准确性。