在统计报表中，按分组计算加权平均值是常见需求。比如电商平台要计算每个商品类目的平均成交单价，如果直接对单价求平均，会忽略不同商品的销量差异，得到的结果可能偏离真实业务指标。加权平均的公式是权重与数值乘积之和除以权重之和，在 SQL 中可以利用 SUM 函数配合除法运算实现，并且能够与 GROUP BY 结合完成分组统计。本文从基础公式出发，逐步讲解如何处理空值、除零以及多维度分组等实际场景。
一、为什么不能直接用 AVG 计算加权平均
普通平均函数 AVG 在计算时对每一行数据一视同仁，不会考虑不同记录在业务上的重要程度。以销售场景为例，商品 A 单价 10 元，卖出 100 件；商品 B 单价 50 元，只卖出 10 件。如果直接对单价求平均，结果是 30 元，但真实的平均成交单价显然应该更接近销量更大的商品 A。按照加权平均公式，应该是（10×100 + 50×10）÷（100+10），结果约为 13.64 元。30 元与 13.64 元的差距说明 AVG 并不适合带权重的统计。
在 SQL 中，如果先按类目分组再使用 AVG(price)，数据库只会把所有单价加起来除以行数，销量字段根本不会参与计算。比如某个类目下有三个商品，价格分别是 5、20、100，对应销量为 1000、50、1。AVG(price) 的结果是 41.67，而实际加权平均价格大约只有 5.71。这意味着报表中如果出现高价但几乎没销量的商品，普通平均会严重拉高指标，进而影响库存、定价或采购决策。
下面的对比查询可以直观看到两种算法的差异。第一个查询使用 AVG 得到算术平均，第二个查询使用 SUM 与除法得到加权平均。后者才是更符合业务逻辑的结果。
-- 普通算术平均
SELECT
category,
AVG(price) AS avg_price
FROM sales
GROUP BY category;
-- 加权平均
SELECT
category,
SUM(price * quantity) / SUM(quantity) AS weighted_avg_price
FROM sales
GROUP BY category;
二、使用 SUM 与除法实现分组加权平均
加权平均的本质是先将每个数值乘以其对应权重，再将所有乘积相加，最后除以权重之和。在 SQL 里，SUM 函数不仅能够对单列求和，还可以接受表达式作为参数。因此我们可以把分子写成 SUM(price * quantity)，分母写成 SUM(quantity)，再通过除号连接起来。数据库执行查询时，会先根据 GROUP BY 字段把数据划分成多个小组，然后在每个小组内分别计算分子和分母，最后做一次除法。
为了演示具体写法，先准备一张销售明细表。表结构中包含商品类目、商品名称、单价和销售数量，插入数据时故意让不同商品之间的销量差异较大，这样加权平均与算术平均的区别会更明显。
CREATE TABLE sales (
id INT PRIMARY KEY,
category VARCHAR(50),
product_name VARCHAR(100),
price DECIMAL(10,2),
quantity INT
);
INSERT INTO sales VALUES
(1, '电子产品', '耳机', 100.00, 200),
(2, '电子产品', '充电器', 30.00, 500),
(3, '电子产品', '音箱', 300.00, 5),
(4, '日用品', '毛巾', 15.00, 300),
(5, '日用品', '水杯', 25.00, 150),
(6, '日用品', '收纳盒', 60.00, 20);
执行分组加权平均查询后，数据库会先将电子产品组的三个商品计算为（100×200 + 30×500 + 300×5）÷（200+500+5），得到该组的平均成交单价；日用品组也按同样方式处理。最终每个类目只返回一行结果，适合直接用于汇总报表。
SELECT
category,
SUM(price * quantity) / SUM(quantity) AS weighted_avg_price
FROM sales
GROUP BY category;
这种写法的优点是简洁且通用，几乎所有主流关系型数据库都支持。只要分组字段明确，SUM 配合除法就能准确反映权重对平均值的影响。需要注意的是，如果某个类目下所有销售数量都为 0，或者数量字段存在空值，直接相除可能会报错或返回空结果，这些问题需要在下一节单独处理。
三、空值处理与除零保护
SUM 函数对 NULL 值有特殊的处理规则：聚合时会直接忽略 NULL，但如果在表达式中出现了 NULL，则整行计算结果通常也是 NULL。例如 price 为 NULL 时，price * quantity 的结果是 NULL，这一行就不会进入分子求和；quantity 为 NULL 时同理。虽然 SUM 忽略 NULL 看起来不会报错，但它会导致权重丢失，使得最终平均值偏离真实情况。业务上通常需要提前定义空值的默认行为，例如把销量 NULL 看作 0，或者把单价 NULL 看作 0，再参与计算。
除零保护是另一个必须考虑的问题。假设某个分组里所有 quantity 都为 0，或者某些数据库在 SUM 之后得到 0，直接执行除法会触发除零错误。不同数据库的处理方式并不一致：MySQL 在部分配置下可能返回 NULL，而 SQL Server 则会直接报错。为了保证查询在不同环境中稳定运行，建议使用 CASE 表达式或 NULLIF 函数把分母为 0 的情况拦截掉。
下面的查询同时处理了空值和除零问题。COALESCE 函数负责把 NULL 转换为 0，NULLIF 函数负责在数量总和为 0 时返回 NULL，避免除法运算失败。这样即使数据质量不理想，查询也能正常执行，并且业务上可以把 NULL 结果解释为无法计算平均单价。
SELECT
category,
SUM(COALESCE(price, 0) * COALESCE(quantity, 0))
/ NULLIF(SUM(COALESCE(quantity, 0)), 0) AS weighted_avg_price
FROM sales
GROUP BY category;
除了空值和除零，整数除法也可能造成精度问题。在 SQL Server 中，如果分子和分母都是整数类型，除法结果会按整数返回，小数部分被截断。例如 5 除以 2 得到 2 而不是 2.5。要避免这一点，可以在表达式中乘以 1.0 或使用 CAST 把其中一个操作数转成小数。不同数据库对数值类型的要求略有区别，但养成显式转换的习惯可以减少跨库迁移时的意外。
四、窗口函数实现分组内加权平均
GROUP BY 加 SUM 的写法适合只需要分组汇总结果的场景，但如果希望在每一行明细数据后面附加该组的加权平均值，方便比较单个商品与组平均水平的差距，GROUP BY 就显得不太灵活。因为 GROUP BY 会把多行折叠成一行，原始明细随之丢失。此时可以使用窗口函数，将 SUM 与 OVER(PARTITION BY 分组字段) 结合起来，在不缩减行数的情况下完成同样的计算。
窗口函数中的 SUM 不会把多行合并，而是为每一行计算一个基于分区范围的值。比如按 category 分区后，SUM(price * quantity) OVER (PARTITION BY category) 会在每一行上返回该类目的总销售额，SUM(quantity) OVER (PARTITION BY category) 会在每一行上返回该类目的总销量，两者相除就得到该类目的加权平均单价，并且每一行都会重复显示这个组级结果。
SELECT
id,
category,
product_name,
price,
quantity,
SUM(price * quantity) OVER (PARTITION BY category)
/ NULLIF(SUM(quantity) OVER (PARTITION BY category), 0) AS category_weighted_avg
FROM sales
ORDER BY category, id;
与 GROUP BY 相比，窗口函数的好处是能够同时保留明细和汇总信息，适合做行级分析、排名、偏差计算等后续操作。例如可以在外层查询中直接用当前商品的单价减去分组加权平均值，得到该商品相对于组均价的偏离程度。不过窗口函数对数据库版本有一定要求，MySQL 8.0 之前的版本不支持，PostgreSQL、SQL Server 和 Oracle 较早版本均已支持。大表上使用窗口函数时还要注意分区字段的索引和排序开销，避免性能下降。
实际开发中，选择哪种写法取决于输出需求。如果报表只需要每个分组一行，优先使用 GROUP BY；如果需要在明细上附加分组指标，则使用窗口函数。两种方案的核心公式相同，都要注意空值、除零和精度问题。掌握了 SUM 与除法的组合，再配合 GROUP BY 或窗口函数，就能灵活应对大部分分组加权平均的计算场景。