如何用SQL快速实现排名占比计算：SUM与OVER组合
用 SUM() OVER() 算排名占比，本质是“先算总数、再算累计、最后除一下”
说到排名占比，新手常有个误区：以为排个序、标个序号就完事了。其实不然，真正的排名占比，是要看每个值在整体中的累计比例——比如，想知道销售额前三名总共占了多大份额。这时候，ROW_NUMBER() 或 RANK() 就派不上用场了，必须请出窗口函数来动态聚合。核心思路非常清晰：先用 SUM() OVER(ORDER BY ...) 算出升序累计和，再除以总和，占比自然就出来了。
SUM() OVER(ORDER BY ...) 的 ORDER BY 不能漏，否则累计失效
这里有个关键细节：ORDER BY 子句千万不能省。如果只用 SUM(sales) OVER()，那得到的就是整张表的销售总和，每行结果都一样，根本体现不出“从高到低累计”的效果。真正的排名占比计算，必须明确排序依据，比如按销售额降序排列。而且，窗口函数默认的帧范围——ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW——恰好完美契合了累计计算的需求，通常无需额外声明。
- 典型错误：
SUM(sales) OVER()→ 每行都显示总销售额，无法计算排名过程中的动态占比。 - 正确姿势：
SUM(sales) OVER(ORDER BY sales DESC)→ 每行显示从最高值到当前行的累计销售额。 - 进阶提醒：如果排序字段存在重复值（比如多人销售额相同），建议在
ORDER BY后加上一个唯一键（如ORDER BY sales DESC, id ASC），以确保窗口计算顺序的确定性。
占比 = 累计和 ÷ 总和，总和必须用 SUM() OVER() 而非子查询
计算总和时，有些朋友习惯先用子查询算出总数，再关联回主表。这种方法不仅增加了查询的复杂度，影响性能，还容易引入错误。其实，窗口函数完全有能力在同一查询层级搞定一切：用一个不带 ORDER BY 的 SUM() OVER() 获取总和，再与带排序的累计和配合使用，一气呵成。
SELECT name, sales, SUM(sales) OVER (ORDER BY sales DESC) AS cum_sales, SUM(sales) OVER () AS total_sales, ROUND(SUM(sales) OVER (ORDER BY sales DESC) * 1.0 / SUM(sales) OVER (), 4) AS cum_pct FROM sales_table;
SUM(sales) OVER ()计算整表总和，每行的这个值都相同。- 乘以
1.0是为了避免整数除法导致的小数位截断，在 PostgreSQL 或 SQL Server 中尤其要注意。 - 需要注意的是，MySQL 8.0+ 和 PostgreSQL 都支持此语法，但 SQLite 不支持窗口函数，切勿生搬硬套。
百分比精度和 NULL 处理是上线前最容易翻车的地方
业务报表对数据精度要求严格，通常要求百分比保留两位小数。但直接使用 ROUND(..., 2) 可能导致所有行的累计占比加总后不等于 100%。更棘手的问题是 NULL 值：只要 sales 字段存在 NULL，SUM() OVER() 默认会忽略它，但如果排序时将 NULL 置于开头或中间，就可能造成累计逻辑的中断。
- 统一处理NULL：使用
COALESCE(sales, 0)让字段参与计算，确保累计过程连续。 - 末位修正：如果需要确保最后一行累计占比严格等于1，可以这样处理：
CASE WHEN ROW_NUMBER() OVER() = COUNT(*) OVER() THEN 1.0 ELSE cum_pct END。 - 精度前置：务必在数据库层就确定好精度，不要依赖客户端进行四舍五入，否则前端汇总时极易出现对不上的情况。
总而言之，窗口函数语法看似简洁，但其背后的排序逻辑、NULL 值处理规则以及数据类型隐式转换这几个环节，往往是测试时不易察觉、一上线就暴露问题的“暗礁”。
