用 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 是为了防止整数除法截断（尤其在 SQL Server、MySQL 8.0 前默认行为下）；PostgreSQL 和 Oracle 会自动转为 numeric，但显式乘 1.0 更稳妥。

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

漏掉 PARTITION BY 就等于对全表求和，得到的是“该职级人数 / 全表总人数”，不是分组内占比。这是最常见的误写。

• SUM(COUNT(*)) OVER (PARTITION BY dept) → 每个部门的总人数（正确）
• SUM(COUNT(*)) OVER () → 全表总人数（错误，除非你真要全表占比）
• 嵌套聚合如 COUNT(*) OVER (PARTITION BY dept) 会报错：窗口函数里不能直接对聚合结果再开窗口，必须先 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 对嵌套聚合（COUNT(*) inside SUM() OVER()）解析不稳定，建议拆成 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），且分组后每组数据量极小，OVER() 开销可能反超子查询 —— 这种情况少见，但线上大表跑慢时值得对比执行计划里的 WindowAgg 节点耗时。

真正影响性能的是 GROUP BY 阶段：确保 dept 和 job 上有联合索引（顺序按 GROUP BY 中出现顺序），能避免临时文件排序。