窗口函数慢的主因是work_mem不足导致排序落盘，其次为分区键选择不当、帧定义过宽及索引不匹配；需用explain analyze定位瓶颈，会话级调优work_mem，合理设计分区与帧范围，并建立匹配复合索引。
窗口函数慢，先看是不是 work_mem 不够
PostgreSQL 里窗口函数卡顿，八成是 work_mem 撑不住排序内存需求。它不是在算聚合，而是在每个 PARTITION BY 分区内做完整排序——这个过程全靠 work_mem 堆出来。一超限就落盘，性能断崖下跌。
- 用
EXPLAIN (ANALYZE, BUFFERS)查执行计划，重点找WindowAgg或Sort节点是否带Sort Method: external merge Disk - 查
pg_stat_progress_sort.sort_bytes，如果远大于当前work_mem设置值，说明已溢出 - 别全局改
postgresql.conf：报表类查询才需要大内存，OLTP 查询会被拖垮 - 应用里安全做法是会话级临时调高：
BEGIN; SET LOCAL work_mem = '64MB'; SELECT ... OVER (...); COMMIT; - 用连接池（如 PgBouncer）时，确认没禁用
SET，需配置ignore_startup_parameters = work_mem
SQL Server 2022 要用 WINDOW 子句，但得先升兼容级别
WINDOW 子句不是语法糖，它是编译期优化：把重复的 PARTITION BY + ORDER BY 定义只解析一次，减少执行计划元数据开销。但它只在兼容性级别 160 生效，低于这个值直接报错，不是警告。
- 必须显式执行：
ALTER DATABASE YourDB SET COMPATIBILITY_LEVEL = 160; - 升级后无法回退到 150 或更低（除非重建库），旧版隐式转换行为可能变化，得回归测试
-
WINDOW w AS (PARTITION BY dept_id ORDER BY salary DESC)后，多个函数可共用OVER w，避免重复解析 -
WINDOW不支持动态表达式（比如@col变量）、也不能跨 CTE 或子查询作用域
PARTITION BY 字段选错，比写错 SQL 还致命
窗口函数性能崩盘，常源于分区键本身就不合理。按 user_id 分亿级日志？等于给引擎派发上千万个微型排序任务。分区不是越细越好，而是要兼顾基数、业务语义和数据倾斜。
- 优先选稳定、中低基数字段，如
tenant_id、region、DATE(event_time)，而非user_id或毫秒级时间戳 - 若必须按高基字段计算，先预聚合：比如先按天汇总用户行为，再在小表上开窗
- 检查
EXPLAIN中WindowAgg节点的Partitions数量，超 10 万就要警惕 - 复合索引顺序必须匹配：如
PARTITION BY a, b ORDER BY c，对应索引应为(a, b, c)，不能只建(a) - 避免在
PARTITION BY里用表达式（如date_trunc('month', t)），除非你建了函数索引
ROWS BETWEEN UNBOUNDED PRECEDING 很常用，也很危险
累计求和、排名、移动平均都爱用这个帧定义，但它要求数据库为每一行维护一个不断扩大的滑动状态，无法并行，内存和 CPU 压力随分区大小线性增长。尤其当排序字段无索引或存在大量重复值时，问题更明显。
- 能用
ROWS就别用RANGE：前者按物理行定位，后者需值比较，开销更大 - 限制帧范围：比如
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW比全分区累计快得多，且利于 CPU 缓存局部性 - ORDER BY 字段有大量重复（如只到秒级的
created_at）？补一个唯一字段：ORDER BY created_at, id - 对实时性不高的报表，把窗口计算下推到物化视图或定时任务里，别每次查都重算
- MySQL 8.0 对
UNBOUNDED PRECEDING有部分优化，但 PostgreSQL 直到 16 仍无本质改进，别指望它自动提速
EXPLAIN ANALYZE 说话。
