不能直接在GROUP BY查询中混用聚合函数和窗口函数，因二者行粒度冲突：COUNT()返回每组计数，COUNT() OVER()作用于原始行集，必须用SUM(COUNT(*)) OVER()先聚合再开窗求总和，配合子查询或CTE及100.0强制浮点运算才能正确计算分组占比。
不能直接在 GROUP BY 查询里用 COUNT(*) / COUNT(*) OVER() 算百分比——语法会报错，结果会失真，整数除法还会返回 0。
为什么 GROUP BY + 窗口函数不能裸混用？
SQL 引擎不允许在同一个 SELECT 层级里，一边做聚合（如 COUNT(*)），一边直接调用窗口函数（如 COUNT(*) OVER()）参与计算。这不是写法懒，是语义冲突：聚合后每行代表一个分组，而窗口函数默认作用于原始行集，两者“行粒度”不匹配。
常见错误现象：ERROR: column "xxx" must appear in the GROUP BY clause 或结果全是 0 或 1。
-
COUNT(*)在GROUP BY后是每组的计数值 -
COUNT(*) OVER()默认是对原始表所有行计数，不是对分组结果计数 - 想让分母等于“各组计数之和”，必须用
SUM(COUNT(*)) OVER()，这是合法嵌套
正确写法：先聚合，再用窗口补总数
最稳、兼容性最好的方式是两层结构：内层 GROUP BY 出各组值，外层用窗口函数求总和并相除。
示例（各部门人数占全公司比例）：
SELECT dept, cnt,
ROUND(100.0 * cnt / SUM(cnt) OVER(), 2) AS pct
FROM (
SELECT dept, COUNT(*) AS cnt
FROM employees
GROUP BY dept
) t;
-
100.0 *强制浮点运算，避免整数截断（如3/10 → 0） -
SUM(cnt) OVER()是对子查询结果中所有cnt求和，即全公司总人数 -
ROUND(..., 2)控制小数位，防止浮点误差（如33.3333333333）
分母选 COUNT(*) OVER() 还是 SUM(COUNT(*)) OVER()？
取决于你是否已执行 GROUP BY：
- 没
GROUP BY时，COUNT(*) OVER()= 全表行数 - 有
GROUP BY后，COUNT(*) OVER()仍算原始行数，但你通常要的是“分组后总计”，所以必须用SUM(COUNT(*)) OVER() - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持
SUM(COUNT(*)) OVER()；SQLite 不支持窗口函数，只能用子查询
别信“COUNT(*) OVER() 就够了”的简写——它在 GROUP BY 下几乎总是错的。
容易被忽略的三个坑
实际跑通一条百分比 SQL，光语法对还不够：
-
WHERE条件必须一致：如果主查询加了WHERE status = 'active'，那子查询或 CTE 里也得带上，否则分母含无效数据 - 除零风险：整张表为空，或某分组
COUNT(*)为 0，SUM(cnt) OVER()就是 0，直接除会出错或返回NULL；加NULLIF(SUM(cnt) OVER(), 0)更安全 - 字段类型隐式转换：某些数据库（如旧版 MySQL）对
INT / INT自动截断，务必用100.0 *或显式CAST(cnt AS DECIMAL)
真正麻烦的从来不是怎么写，而是 WHERE 是否同步、NULL 是否干扰、分母到底算的是哪一层的“总”。
