直接用COUNT()做分母会出错，因GROUP BY后COUNT()是每组行数，而计算占比需全表总数，正确分母应为COUNT(*) OVER()；若列含NULL，COUNT(column)会忽略NULL导致分子分母不一致，失真。
为什么直接用 COUNT(*) 做分母会出错
在 GROUP BY 后想算每组占总数的百分比，如果写成 COUNT(*) / COUNT(*) OVER()，看起来合理，但实际会得到 100% —— 因为 COUNT(*) 在分组后是每组的行数，而 COUNT(*) OVER() 是全表行数，**二者量纲不同但能除，结果却是对的**；真正出错的是你用了 COUNT(column) 且该列含 NULL：它会在分组内忽略 NULL，但在窗口里也忽略 NULL，导致分母变小，百分比失真。
正确做法是统一用非空标识来计数：
- 分母必须是全表总行数（不含
NULL干扰），推荐COUNT(*) OVER() - 分子如果是“某字段非空的行数”，就用
COUNT(column_name) OVER (PARTITION BY ...)，但注意这和分组后的COUNT(column_name)行为一致，容易混淆 - 更稳妥的分子写法是
COUNT(*) FILTER (WHERE condition) OVER (PARTITION BY ...)，显式控制逻辑
SUM() OVER() 和 COUNT(*) OVER() 哪个更适合当分母
取决于你要算的是「行占比」还是「值占比」。90% 的场景要的是行占比，比如「每个部门人数占全公司比例」，此时分母必须是 COUNT(*) OVER()；如果你要算「每个部门销售额占总销售额比例」，才用 SUM(sales) OVER() 当分母。
常见误用：SUM(1) OVER() 看似等价于 COUNT(*) OVER()，但它在有 NULL 分组键时行为不稳定（SUM 忽略 NULL，但 1 不会为空），所以别这么写。
- 要行数占比 → 分母用
COUNT(*) OVER() - 要数值加总占比 → 分母用
SUM(numeric_column) OVER() - 避免用
SUM(1) OVER()或AVG(1) OVER()替代计数
如何在 GROUP BY 查询中安全嵌套窗口函数
PostgreSQL 允许在 SELECT 列表中同时出现分组聚合和窗口函数，但顺序和作用域必须理清：窗口函数在分组之后执行，所以 COUNT(*) OVER() 拿到的是分组前的原始行数，而 COUNT(*)（无窗口）是分组后的每组行数——这是你能做除法的基础。
典型结构：
SELECT dept, COUNT(*) AS cnt, ROUND(COUNT(*) * 100.0 / COUNT(*) OVER(), 2) AS pct FROM employees GROUP BY dept;
关键点：
- 不能在
WHERE或HAVING中引用窗口函数结果（它们在窗口计算之前执行） - 如果需要过滤后再算百分比，先用 CTE 或子查询筛数据，再在外层分组+窗口
-
* 100.0是为了触发浮点运算，否则整数除法会截断为 0
遇到 OVER() with ORDER BY 导致百分比异常怎么办
如果你不小心写了 COUNT(*) OVER(ORDER BY dept)，那得到的不是总数，而是“截止当前 dept 的累计计数”，除出来就是累积百分比（cumulative %），不是你想要的各组独立占比。这种错误很难一眼发现，尤其当 dept 值少、排序后分布不均时，数值看起来“差不多”。
检查方法：把窗口函数单独拿出来执行，看结果是不是全列相同值。如果不是，说明加了隐式排序或分区。
- 要总数 → 确保
OVER()是空括号，不带任何子句 - 要分组内总数（如每个部门内按职级占比），才用
OVER(PARTITION BY dept) - 一旦出现
ORDER BY或ROWS BETWEEN，立刻确认是否真需要累积逻辑
最常被忽略的是 CTE 或视图里已经定义了窗口函数，外部查询又叠加分组，导致双重上下文错乱——建议把窗口计算收拢到最外层，避免嵌套层级过多。
