多个OVER子句会变慢，因数据库无法复用不同PARTITION BY或ORDER BY的排序结果，导致多次全表排序；千万级表上三次窗口函数可能触发三次独立排序扫描，I/O与内存开销陡增。
多个OVER子句为什么会变慢
一个查询里写多个 ROW_NUMBER()、COUNT() OVER ()、AVG() OVER (PARTITION BY ...)，数据库引擎往往无法复用排序结果。PostgreSQL 和 SQL Server 在遇到不同 PARTITION BY 或不同 ORDER BY 的窗口函数时，会分别触发独立的排序操作——千万级表上，三次窗口函数可能等于三次全表排序扫描。
常见错误现象：COUNT(*) OVER () 和 ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) 同时出现，执行计划里能看到多个 Sort 节点，I/O 和内存开销陡增。
- 空
OVER()（如COUNT(*) OVER ()）在 PostgreSQL 中默认触发全局排序，不是“无序聚合” - MySQL 8.0+ 虽支持窗口函数，但对多窗口复用优化弱于 PostgreSQL 14+ 或 SQL Server 2022
- 如果所有窗口函数共享同一
PARTITION BY和同一ORDER BY，引擎才可能合并排序；否则一律视为独立窗口
先判断是否真需要多个窗口函数
很多场景下，所谓“多个指标”其实可以用更轻量方式满足，硬套窗口函数反而引入冗余排序。
- 要总行数？优先走
SELECT COUNT(*) FROM t单独查，再用JOIN或应用层拼接——比COUNT(*) OVER ()稳定且可控 - 要“每组最大值 + 当前行排名”，可先用 CTE 物化分组聚合结果，再
JOIN回原表，避免在大表上跑两次MAX() OVER (PARTITION BY ...)和ROW_NUMBER() - 仅需“是否为组内第一条”，用
ROW_NUMBER() = 1过滤后，再加其他字段，比在 SELECT 中保留全部窗口列更省资源
必须用多个OVER时的实操压缩策略
当业务逻辑强依赖多个不同维度的窗口计算（比如同时按部门、按时间范围、按状态分组做累计和排名），就得从写法和执行路径上收口。
- 显式统一排序键：把所有
ORDER BY尽量收敛到同一列组合，例如都用ORDER BY dept, created_at DESC, id，哪怕部分窗口没用到id，也能提高排序复用概率 - 用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW替代默认框架，防止引擎因不确定边界而退化为RANGE模式（尤其在时间字段有重复值时） - 在 PostgreSQL 中，开启
enable_sort = on并确保work_mem足够（如 64MB+），避免排序落盘；SQL Server 则建议启用QUERYTRACEON 9481强制新 Cardinality Estimator 提升窗口估算精度 - 避免嵌套窗口：如
ROW_NUMBER() OVER (ORDER BY MAX(sales) OVER (PARTITION BY region))，这种写法会强制两轮窗口计算，直接拆成 CTE 两步走更清晰、更易优化
替代方案：CTE + JOIN 比纯窗口更可控
对大表（>500 万行），多数时候“先聚合、再关联”比“一行一算多个窗口”性能更稳、计划更可读。
例如想同时拿到：部门平均薪资、个人薪资排名、所在部门薪资中位数。
- 错误写法：
AVG(salary) OVER (PARTITION BY dept)+ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary)+PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) OVER (PARTITION BY dept)—— 三套独立 PARTITION + 排序 - 推荐写法：用 CTE 先算部门聚合（含 avg、median），再
JOIN回原表，最后补上ROW_NUMBER()（只跑一次排序） - 额外好处：CTE 结果可被物化（PostgreSQL 12+ 默认开启
materialize，SQL Server 需加OPTION (RECOMPILE)配合临时表）
真正难优化的从来不是语法本身，而是窗口函数掩盖了“本该提前裁剪的数据量”。别让 OVER (PARTITION BY user_id) 在十亿用户表上运行——先用 WHERE 或分区剪枝缩小数据集，再上窗口，顺序不能错。
