窗口函数加COUNT(*)做占比慢是因为数据库为每个窗口重复扫描全量数据，尤其高基数分区时触发多次排序与扫描；应改用两层子查询或物化CTE，删除无谓ORDER BY，并确保分母提前固化。
窗口函数加 COUNT(*) 做占比为什么慢得离谱
因为数据库默认会为每个窗口重新扫描全量数据，尤其当 PARTITION BY 字段高基数（比如用户 ID）、且数据量上亿时，SUM(COUNT(*)) OVER() 这类嵌套聚合会触发多次排序 + 多轮扫描，CPU 和内存压力陡增。
- 别写
SUM(COUNT(*)) OVER()—— 这是常见反模式，优化器通常无法下推聚合，实际执行计划里能看到重复的 WindowAgg 节点 - 改用两层子查询：外层算总数，内层算分组计数，再相除。虽然 SQL 稍长，但能强制走 HashAggregate，避免窗口排序开销
- 如果数据库支持物化 CTE（如 PostgreSQL 12+、SQL Server），把分组计数结果先
WITH counts AS (SELECT group_col, COUNT(*) c FROM t GROUP BY group_col)再 JOIN 总数，性能提升常达 3–5 倍
OVER(PARTITION BY ... ORDER BY ...) 中 ORDER BY 是性能黑洞
只要窗口定义里带 ORDER BY，哪怕你只想要占比，数据库也必须做完整排序——这对上亿行就是灾难。占比计算本身根本不需要顺序。
- 删掉
ORDER BY，只保留PARTITION BY。例如：COUNT(*) OVER(PARTITION BY category)✅；COUNT(*) OVER(PARTITION BY category ORDER BY id)❌（除非真要累计占比） - 如果业务真需要“按时间排序后的滚动占比”，优先考虑用应用层分页 + 缓存中间结果，而不是硬扛窗口排序
- PostgreSQL 用户注意：
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这种框架也会强制排序，和ORDER BY效果等价
GROUP BY + 子查询比窗口函数更快的三个条件
不是所有场景都该弃用窗口函数，但大数据量下，传统分组往往更可控、更容易命中索引。
- 分组字段有高效索引（B-tree 或 BRIN），且选择率不高（比如状态码只有 5 种）
- 结果集远小于原始数据量（比如 10 亿行 → 几千个分组），此时
GROUP BY的 Hash 表内存占用低 - 能接受两次扫描（一次算分组数，一次算总数），因为两次全表扫描 + 索引聚合，仍比一次带排序的窗口快
示例：代替 ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER(), 2)，改写为
SELECT category, ROUND(c::numeric / t.total * 100, 2) AS pct FROM ( SELECT category, COUNT(*) c FROM orders GROUP BY category ) c CROSS JOIN (SELECT COUNT(*) total FROM orders) t
MySQL 8.0 和 ClickHouse 对占比计算的处理差异
MySQL 8.0 的窗口函数在大表上容易 OOM 或超时，而 ClickHouse 的 sum(count()) OVER() 虽语法支持，但底层仍是分块并行，若未配合适当 PREWHERE 或跳过索引，照样慢。
- MySQL：关掉
optimizer_switch='window_functions=off'没用，真正有效的是加SQL_BIG_RESULT提示，让优化器倾向用临时表而非排序 - ClickHouse：用
sum(count(*)) OVER ()前，务必确认GROUP BY已经落在ORDER BY前缀上（比如表建模时把分组字段放ORDER BY (category, dt)开头），否则窗口无法复用排序结果 - 两者共性：占比分母如果是全表
COUNT(*)，千万别在窗口里实时算，提前固化成变量或物化视图
真正卡住性能的，往往不是语法怎么写，而是没意识到占比本质是「两个独立聚合的比值」——强行塞进一个窗口，等于让数据库多做一堆无意义的排序和分区维护。
