窗口函数性能瓶颈主要在windowagg节点，需检查执行计划中rows removed by Filter和缓存命中率；partition by字段须建匹配复合索引；慎用unbounded preceding帧；优先考虑group by、cte或应用层分批等替代方案。
窗口函数慢，先看执行计划里有没有 WindowAgg
postgresql 和大多数现代数据库在执行窗口函数时，会把逻辑编译成 WindowAgg 节点；如果这个节点出现在执行计划顶部或靠近顶部，且估算行数大、实际耗时高，基本可以判定瓶颈就在这里。不是语法写错了，而是数据量和窗口范围共同放大了计算开销。
实操建议：
- 用
EXPLAIN (ANALYZE, BUFFERS)查看真实执行路径，重点关注WindowAgg的Rows Removed by Filter和Shared Hit Blocks—— 如果命中率低、读盘多，说明缓存没起作用 - 避免在未索引的排序字段上做
ORDER BY窗口（比如ORDER BY created_at DESC但created_at没索引），数据库会强制排序，代价远超聚合本身 - 如果只用
ROW_NUMBER()或RANK()做分页去重，考虑是否能用LIMIT/OFFSET+ 主键范围扫描替代——窗口函数不是万能分页解药
PARTITION BY 字段必须有高效索引
窗口函数的 PARTITION BY 不是过滤条件，它决定数据分组边界；数据库需要快速定位每个分区的起止位置。没有索引时，引擎只能全表扫描+哈希分组，内存占用飙升，还容易触发磁盘溢出（Temp file written）。
实操建议：
- 复合索引顺序要匹配：比如
PARTITION BY user_id, status ORDER BY event_time，对应索引应为(user_id, status, event_time)，不能只建(user_id) - 别在
PARTITION BY里用表达式（如PARTITION BY date_trunc('month', occurred_at)），除非你给该表达式建了函数索引 - 分区键基数太高（比如每行都不同）会让窗口失去意义——检查业务逻辑是否误用了高基列，换成更粗粒度的分组维度（如按天而非按毫秒）
慎用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
这是累计求和/排名最常用的帧定义，但也是性能杀手。数据库必须为每一行维护一个不断增长的滑动状态，无法并行、难优化，尤其当分区大、排序字段无序时，CPU 和内存压力直线上升。
实操建议：
- 如果只需要最新 N 条记录的累计值（比如最近 7 天销售额），改用
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW—— 固定窗口能让优化器预分配内存，也更容易利用 CPU 缓存局部性 - 对实时性要求不高的场景（如日报统计），把窗口计算下推到物化视图或定时任务里，避免每次查询都重算
- mysql 8.0+ 对
ROWS UNBOUNDED PRECEDING有部分优化，但 PostgreSQL 直到 16 版仍依赖内存排序；别假设“新版本就快”，得实测
替代方案比硬调窗口函数更有效
很多以为非窗口不可的场景，其实用关联子查询、CTE 预聚合或应用层分批处理更稳。窗口函数本质是“单次扫描多路输出”，一旦数据倾斜或内存不足，整个查询就卡住，而替代方案往往可中断、可重试、资源可控。
实操建议：
- 想查每个用户的首笔订单时间？别用
MIN(order_time) OVER (PARTITION BY user_id)，改用select user_id, MIN(order_time) FROM orders GROUP BY user_id再 JOIN —— 少一次全量扫描 - 要做复杂漏斗分析（比如 A→B→C 转化率）？用多个 CTE 分步聚合，比在一个窗口里嵌套多层
CASE WHEN更易调试、更少 OOM 风险 - 应用层处理大批量数据时，别让数据库返回带窗口结果再过滤；先用主键范围分片，再在代码里做轻量级累计计算——网络传输和内存压力常被低估
窗口函数不是银弹，它的简洁性背后藏着隐式资源契约：你要保证分区够小、排序够快、帧定义够稳。否则越“优雅”的写法，越容易在线上突然变慢。