在做数据报表时，占比计算几乎是绕不开的需求。比如运营想看各渠道带来的用户量占总用户量的比例，财务想看各产品线的收入占比，分析师想看每个城市订单量在全国的分布情况。这类问题如果用传统SQL思路来解决，通常要先查询出总量，再用JOIN关联回原表做除法，不仅SQL写得冗长，而且多表关联在大数据量下性能会明显下降。其实SQL的窗口函数天生就是为这类问题设计的，一条查询就能完成占比计算，下面我们详细展开。
一、为什么窗口函数是占比计算的最佳选择
先看一个常见的错误写法。假设有一张销售明细表sales，包含字段product（产品）、region（区域）、amount（销售额），很多人会这样算各产品的销售占比：
-- 传统写法：子查询求总量再相除
SELECT
product,
SUM(amount) AS product_amount,
SUM(amount) / (SELECT SUM(amount) FROM sales) AS ratio
FROM sales
GROUP BY product;
这种写法在单维度场景下勉强能用，但存在几个问题。第一，子查询会额外扫一遍表，数据量大时开销不可忽视；第二，如果需求升级为“每个区域内部各产品的占比”，子查询就需要改成先按区域聚合再关联，复杂度直线上升；第三，除法涉及整数相除时容易被截断，需要额外处理类型转换。
窗口函数的思路完全不同。它在聚合之后不折叠行，而是把聚合结果作为一个“窗口值”附加到每一行上，这样分子分母可以在同一次扫描中同时得到。核心公式可以概括为：
-- 窗口函数占比通用公式
SELECT
product,
SUM(amount) AS product_amount,
SUM(amount) * 1.0 / SUM(SUM(amount)) OVER () AS ratio
FROM sales
GROUP BY product;
这里有一个容易被初学者忽略的细节：SUM(SUM(amount)) OVER ()看起来像是写重复了，实际上内层的SUM(amount)是普通聚合，外层的SUM(...) OVER ()是对聚合后的结果再做窗口求和。SQL的执行顺序是FROM、WHERE、GROUP BY、HAVING之后才计算SELECT中的窗口函数，所以这种嵌套是完全合法的，这也是窗口函数占比计算公式最精髓的地方。
二、单维度、多维度与分组内占比的完整写法
1. 全局占比
全局占比是指各项占所有数据总和的比例，这是最简单的场景。只需要OVER ()后面不带任何参数，表示窗口覆盖整个结果集：
SELECT
region,
SUM(amount) AS region_amount,
ROUND(SUM(amount) * 100.0 / SUM(SUM(amount)) OVER (), 2) AS pct
FROM sales
GROUP BY region
ORDER BY pct DESC;
注意这里乘了100.0而不是100，目的是让除法走浮点或 decimal 运算。在MySQL中整数除以整数会得到整数，这是占比计算最经典的坑之一。用ROUND保留两位小数可以让报表更整洁。
2. 分组内占比（PARTITION BY的用武之地）
更常见的需求是“在每个区域内部，各产品的销售额占比是多少”。这时只需在OVER子句中加上PARTITION BY：
SELECT
region,
product,
SUM(amount) AS product_amount,
ROUND(SUM(amount) * 100.0 / SUM(SUM(amount)) OVER (PARTITION BY region), 2) AS pct_in_region
FROM sales
GROUP BY region, product
ORDER BY region, pct_in_region DESC;
执行逻辑可以理解为两步：先按region和product分组聚合得到每个产品的销售额，然后按region分区，在每个分区内对产品销售额求和作为分母。每个区域的占比加起来正好是100%，这正是分组内占比应有的语义。
3. 多维度组合占比
如果维度不止两个，比如要同时看“每个区域、每个月内各产品的占比”，直接扩展GROUP BY和PARTITION BY即可：
SELECT
region,
DATE_FORMAT(order_date, '%Y-%m') AS month,
product,
SUM(amount) AS product_amount,
ROUND(SUM(amount) * 100.0 / SUM(SUM(amount)) OVER (PARTITION BY region, DATE_FORMAT(order_date, '%Y-%m')), 2) AS pct
FROM sales
GROUP BY region, DATE_FORMAT(order_date, '%Y-%m'), product;
需要强调的一点是，PARTITION BY中的字段必须和GROUP BY的分组逻辑保持一致，分母的计算范围就是PARTITION BY定义的范围。写多维度占比时建议先把GROUP BY确定下来，再对照着写PARTITION BY，不容易出错。
三、性能对比、兼容性与常见踩坑点
从性能角度看，窗口函数方案通常优于子查询关联方案。窗口函数只需对聚合后的结果集做一次分区计算，而子查询方案要么多扫一遍原始表，要么把聚合结果再JOIN回明细表。在千万级别的明细表上测试，窗口函数写法的执行时间往往只有JOIN写法的一半甚至更低，而且随着维度增多，JOIN方案的SQL会越写越复杂，窗口函数只需加几个字段，优势更明显。
在兼容性方面，主流数据库对窗口函数的支持情况如下：MySQL从8.0版本开始支持，低于8.0的版本只能退回子查询写法；PostgreSQL、SQL Server、Oracle、Hive、ClickHouse都支持窗口函数，语法基本一致，但细节有差异。比如SQL Server中整数相除同样会截断，建议统一乘1.0或100.0处理；Hive中使用ROUND(x, 2)配合DOUBLE类型可以正常工作；ClickHouse甚至提供了专门的ratio相关函数，但窗口写法依然通用。
最后整理几个高频踩坑点。第一，分母为零的问题：如果某个分区聚合结果全为0，除法会产生除零错误或NULL，可以用NULLIF处理，写成SUM(amount) * 100.0 / NULLIF(SUM(SUM(amount)) OVER (...), 0)，让结果为NULL而不是报错。第二，展示格式问题：如果希望输出带百分号，可以用CONCAT拼接，如CONCAT(ROUND(ratio * 100, 2), '%')。第三，不要把窗口函数写在WHERE里做过滤，窗口函数在WHERE之后才执行，想按占比筛选需要套一层子查询或在支持QUALIFY语法的数据库中使用QUALIFY子句。掌握这些细节后，多维度占比分析的SQL就可以做到既简洁又高效。