SQL如何统计分组内的占比情况_SUM聚合函数结合OVER子句

用 SUM() OVER(PARTITION BY ...) 计算分组内占比最简洁，分子为当前行聚合值，分母为同组总和；需先 GROUP BY 再套窗口函数，避免整数除法截断，注意数据库版本兼容性。

怎么用 SUM() OVER() 计算分组内占比

说到计算分组内的占比，SUM() 配合 OVER() 子句堪称是最优雅的方案之一。它最大的好处是什么？简洁。你不再需要写一堆子查询或者自连接，一个窗口函数就能搞定。它的核心逻辑非常清晰：分子是当前行所在分组的聚合值，分母则是整个分组的总和——而这两者的计算范围，都由 OVER(PARTITION BY ...) 这个子句来精确控制。

举个例子就明白了。假设你想统计每个部门里，不同职级的人数占该部门总人数的比例，可以这么写：

SELECT dept, job, COUNT(*) AS cnt,
       COUNT(*) * 1.0 / SUM(COUNT(*)) OVER (PARTITION BY dept) AS ratio
FROM employees
GROUP BY dept, job;

这里有个细节值得注意：COUNT(*) * 1.0。为什么要乘上 1.0？这是为了防止整数除法带来的小数位截断问题。尤其是在 SQL Server 或者 MySQL 8.0 之前的版本里，默认的整数除法会直接丢掉小数部分。虽然 PostgreSQL 和 Oracle 会自动进行类型转换，但显式地乘上 1.0 或者使用 CAST，能让代码的意图更明确，也更具跨数据库的稳健性。

为什么不能只写 SUM() OVER() 不加 PARTITION BY

这是新手常踩的一个坑。如果把 PARTITION BY 子句漏掉了，那 SUM() OVER() 的计算范围就变成了整个结果集。最终你得到的会是“某个职级人数占全公司总人数的比例”，而不是我们想要的“占本部门总人数的比例”。一字之差，结果天差地别。

• SUM(COUNT(*)) OVER (PARTITION BY dept) → 计算的是每个部门的总人数（这是对的）。
• SUM(COUNT(*)) OVER () → 计算的是全表的总人数（除非你确实需要全表占比，否则这就是错的）。

另外，还要警惕另一种错误写法：试图在窗口函数里直接嵌套聚合。比如 COUNT(*) OVER (PARTITION BY dept) 这样的语句是会报错的。原因在于，窗口函数的计算是在 GROUP BY 之后进行的，你必须先完成分组聚合，再把聚合结果（比如 COUNT(*)）作为窗口函数的输入。正确的顺序永远是：先 GROUP BY，再套上 OVER。

不同数据库对 COUNT(*) OVER() 的支持差异

虽然窗口函数如今已是主流，但各数据库的支持情况和细节上仍有差异。像 MySQL 8.0+、PostgreSQL 11+、SQL Server 2005+ 以及 Oracle 20c+ 这些现代版本，都完美支持上面提到的写法。不过，有些特殊情况需要留意：

• MySQL 5.7 及更早版本完全不支持窗口函数，遇到这种环境，老办法——关联子查询——就得派上用场了。
• SQLite 3.25+ 虽然支持窗口函数，但 COUNT(*) 在窗口中的使用需要配合 GROUP BY。直接写 COUNT(*) OVER() 可能会遇到语法错误。
• 在一些旧版本的 Hive 或 Spark SQL 中，引擎对“在窗口函数内嵌套聚合”这种写法的解析可能不太稳定。为了保险起见，更推荐使用 CTE（公用表表达式）将逻辑拆解开来，这样可读性和兼容性都更好：

  WITH grp_cnt AS (
    SELECT dept, job, COUNT(*) AS cnt
    FROM employees GROUP BY dept, job
  )
  SELECT dept, job, cnt,
         cnt * 1.0 / SUM(cnt) OVER (PARTITION BY dept) AS ratio
  FROM grp_cnt;

性能关键点：PARTITION BY 列要有索引吗

一个常见的误解是，为了优化窗口函数，需要特意为 PARTITION BY 的列创建索引。其实不然。窗口函数执行时的性能瓶颈主要在于排序，而查询优化器通常会根据 GROUP BY 或 ORDER BY 子句自动决定是否进行排序操作。

那么，什么情况下窗口函数的开销会变大呢？一种比较极端的情形是：PARTITION BY 的列基数非常高（例如是用户ID），导致分成海量的小组，每组只有寥寥几条数据。这时，窗口函数为每个微小分区进行计算的 overhead（开销），有可能会超过传统的子查询方法。当然，这种情况在实践中并不常见。不过，当你面对线上大表查询变慢时，检查执行计划里 WindowAgg 节点的耗时，总是一个不错的诊断思路。

真正对这类查询性能影响巨大的，其实是 GROUP BY 阶段。确保在 dept 和 job 这两个用于分组的列上建立联合索引（并且索引列的顺序最好与 GROUP BY 子句中间出现的顺序一致），可以极大地避免数据库进行耗时的临时文件排序，这才是提升效率的关键所在。