正确做法是用SUM(COUNT()) OVER()先聚合再开窗求总和，配合100.0强制浮点运算；不能直接在GROUP BY层级混用COUNT()和COUNT(*) OVER()，否则报错或结果失真。
GROUP BY 后怎么算每个组的占比（占总数的比例）
直接用 COUNT(*) 除以总数就行，但要注意不能在同一个层级直接用聚合函数除——得靠窗口函数或者子查询。最稳的方式是用 SUM(COUNT(*)) OVER()：它先按 GROUP BY 聚合，再对结果集整体求和，避免了手动查总数再 JOIN 的麻烦。
常见错误是写成 COUNT(*) / COUNT(*) OVER()，这会按行计算，不是按组；或者用子查询但没加 WHERE 条件对齐，导致总数不准。
示例（统计每种订单状态的占比）：
SELECT status, COUNT(*) AS cnt, ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(), 2) AS pct_of_total FROM orders GROUP BY status;
-
SUM(COUNT(*)) OVER()是关键，它不依赖PARTITION BY，所以对所有组返回同一总数 - 乘
100.0是为了强制浮点运算，避免整数截断（尤其在 PostgreSQL 或 SQL Server 中） - MySQL 8.0+、PostgreSQL、SQL Server 都支持；SQLite 不支持窗口函数，得用自连接或变量模拟
怎么按某个字段排序后算分组内的累计百分比
比如“按销售额从低到高排列客户，算前 N 个客户贡献了多少销售额，占本地区总销售额的百分比”。这时候要两层窗口：内层算分组内累计和，外层再除以分组内总数。
容易踩的坑是漏掉 PARTITION BY，导致跨地区累加；或者排序字段有重复值时，ROWS UNBOUNDED PRECEDING 和 RANGE 行为不同（推荐用 ROWS，更可控）。
示例（各地区客户销售额累计占比）：
SELECT
region,
customer_id,
amount,
SUM(amount) OVER (PARTITION BY region ORDER BY amount ROWS UNBOUNDED PRECEDING) AS cumsum_amt,
ROUND(
SUM(amount) OVER (PARTITION BY region ORDER BY amount ROWS UNBOUNDED PRECEDING) * 100.0 /
SUM(amount) OVER (PARTITION BY region),
2
) AS cum_pct_in_region
FROM sales;
-
PARTITION BY region确保累计只在本地区内发生 -
ORDER BY amount决定累计顺序；如果想从高到低，改成ORDER BY amount DESC - 分母用
SUM(amount) OVER (PARTITION BY region)，不是SUM(amount) OVER()，否则就变成占全局比例了
为什么用窗口函数比子查询 + JOIN 更可靠
子查询方式要先聚合再 JOIN 总数，一旦分组键有 NULL、类型不一致、或过滤条件没同步，就容易少行或多行。窗口函数天然对齐，语义清晰。
性能上，现代引擎（如 PostgreSQL 14+、BigQuery）对 SUM(COUNT(*)) OVER() 会做优化，实际只扫描一次；而子查询可能触发重复聚合或临时表。
但注意：如果数据库不支持窗口函数（比如 MySQL 5.7 或旧版 SQLite），就得退回到子查询 + LEFT JOIN，此时务必检查 GROUP BY 字段是否允许 NULL，以及 JOIN 条件是否严格匹配（例如用 IS NOT DISTINCT FROM 处理 NULL）。
NULL 值和空分组会让累计百分比出错吗
会。默认情况下，GROUP BY 会把 NULL 当作一个独立分组；但如果你的业务逻辑里 NULL 表示“未知”，不该参与占比计算，就得提前 WHERE field IS NOT NULL 过滤。
另一个陷阱：当某组数据全为空（比如某地区没销售记录），SUM(amount) OVER (PARTITION BY region) 返回 NULL，会导致累计占比整列变 NULL。解决方法是用 COALESCE(SUM(amount) OVER (...), 0)，但更合理的是确认业务是否需要保留空分组——多数时候应该用 HAVING COUNT(*) > 0 或前置过滤。
最后提醒：累计百分比超过 100% 通常是排序字段有重复 + RANGE 模式导致的重复计数，换成 ROWS 就能避开。
