使用 COUNT(*) OVER() 计算分组占比最稳妥，避免子查询重复扫描和WHERE不一致；需用CONVERT/CAST防整数截断，NULLIF防除零错误，且OVER()在GROUP BY后作用于聚合结果。
GROUP BY 后怎么算每个分组占总数的百分比
直接在 GROUP BY 查询里除以总数，最稳妥的方式是用 COUNT(*) OVER()。SQL Server 不支持在聚合函数中直接引用外部总计，但 OVER() 子句能让你在不破坏分组的前提下拿到全局行数。
常见错误是写成 COUNT(*) / (SELECT COUNT(*) FROM table) —— 这不仅多一次扫描，还容易因 WHERE 条件不一致导致结果错乱。
- 确保
OVER()的窗口范围和主查询的过滤逻辑完全一致（比如 WHERE 条件要套在外部或同步写进OVER()的PARTITION BY里） - 用
CONVERT(DECIMAL(5,2), ...)或CAST(... AS DECIMAL(5,2))避免整数除法截断（例如3/10得0，不是0.3） - 如果按多个字段分组，
COUNT(*) OVER()依然有效；它默认是“全表未分区”，不受GROUP BY影响
示例：
SELECT category, COUNT(*) AS cnt, CONVERT(DECIMAL(5,2), COUNT(*) * 100.0 / COUNT(*) OVER()) AS pct FROM sales WHERE status = 'completed' GROUP BY category;
想按某个维度占比，但又不想丢失其他字段信息
这时候别急着 GROUP BY，先用 OVER(PARTITION BY ...) 算局部计数，再结合全局计数做比例。典型场景：查每个部门里「高级职称」人数占本部门总人数的百分比，同时还要显示员工姓名、职级等明细。
关键点在于两个 COUNT(*) OVER() 要区分清楚作用域：
-
COUNT(*) OVER(PARTITION BY dept)→ 每个部门内人数 -
COUNT(*) OVER()→ 全表总人数（或加 WHERE 后的总人数）
注意：如果只需要部门内占比（如“高级职称占本部门 60%”），就用 COUNT(*) OVER(PARTITION BY dept) 做分母，而不是全局总数。
示例（部门内占比）：
SELECT
name, dept, title,
COUNT(*) OVER(PARTITION BY dept, title) AS title_cnt_in_dept,
COUNT(*) OVER(PARTITION BY dept) AS dept_total,
CONVERT(DECIMAL(5,2),
COUNT(*) OVER(PARTITION BY dept, title) * 100.0 /
NULLIF(COUNT(*) OVER(PARTITION BY dept), 0)
) AS pct_in_dept
FROM employees;NULLIF 是必须加的吗？除零错误到底会不会报
会报。SQL Server 在运行时遇到分母为 0 就直接抛 Msg 8134, Level 16, State 1, Line X — Divide by zero error encountered.，哪怕你后面接了 ISNULL 或 CASE 也不行——因为表达式求值顺序中除法先执行。
NULLIF(denominator, 0) 是唯一安全、简洁、可读性强的写法。它把 0 换成 NULL，而任何数除以 NULL 结果也是 NULL，不会中断查询。
- 不要用
CASE WHEN denominator = 0 THEN NULL ELSE numerator/denominator END—— 分母仍会被计算一次，照样报错 - 不要依赖应用层捕获异常来兜底，这是数据库层该拦住的问题
- 即使你知道分母“不可能为 0”，也建议加上
NULLIF，防止未来数据变更或 WHERE 条件调整后意外触发
为什么用 COUNT(*) OVER() 比子查询快得多
执行计划里，COUNT(*) OVER() 只扫一遍表（或索引），聚合值作为“附加列”广播到每行；而子查询方式（如 (SELECT COUNT(*) FROM t)）在每组结果行上都可能触发一次独立执行，尤其在分组多、数据量大时，I/O 和 CPU 开销明显上升。
实际观察执行计划：OVER() 对应的是一个 Window Aggregate 算子，子查询则常表现为嵌套的 Compute Scalar + Constant Scan 或更糟的 Index Scan。
额外提醒：
- 如果表很大且只关心近似比例，别为了省点性能去用统计信息估算（如
sys.dm_db_partition_stats），误差不可控 -
COUNT(*) OVER()的性能几乎不受分组字段数量影响；但加了PARTITION BY后，若分区键选择性差（如只有 2–3 个值），可能引发内存溢出警告（Warning: Null value is eliminated by an aggregate or other SET operation.实际是 memory grant 不足）
真正容易被忽略的是：OVER() 的逻辑发生在 GROUP BY 之后，所以它看到的是已聚合的结果集行数，不是原始明细行数——除非你没写 GROUP BY，而是用窗口函数做明细行计算。
