窗口函数性能瓶颈源于排序与内存不足，需通过执行计划定位windowagg和filesort，建立partition by与order by的复合索引，限制窗口帧范围，并确保分区键对齐分片键。

窗口函数慢，先看执行计划里有没有 WindowAgg 节点和 Using filesort

执行计划是判断瓶颈的第一手依据。如果 EXPLAIN ANALYZE 显示 WindowAgg 节点的 actual time 占比极高，且 Extra 列出现 Using filesort 或 Using temporary，基本可断定是排序或内存不足导致的性能问题。

• 重点观察 rows 值是否远超单表实际数据量——这说明数据被跨节点拉取或重复扫描
• Sort 操作出现在 WindowAgg 之前，且耗时长，说明 ORDER BY 字段没走索引
• PostgreSQL 中若看到磁盘溢写（disk: xxxkB），意味着工作内存 work_mem 不足，或分区太大无法全量驻留内存

PARTITION BY 和 ORDER BY 字段必须建复合索引

窗口函数不是“语法糖”，它本质是一次分组+一次排序。数据库不会自动为你优化这个过程，必须显式提供物理支撑。

• 索引顺序必须严格匹配：例如 ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date)，对应索引应为 (dept_id, hire_date)，不能反过来
• 避免在 ORDER BY 中使用表达式，如 ORDER BY UPPER(name) —— 普通索引无效，需额外建函数索引，且代价高
• 若业务允许，把高基数字段降维：比如用 DATE(created_at) 替代 created_at 分区，减少分区数量

别让窗口帧（frame）无限制膨胀

默认的 RANGE UNBOUNDED PRECEDING 在累计类计算中极易失控。每行都要遍历整个分区，性能随分区大小线性恶化。

• 优先用 ROWS BETWEEN 替代 RANGE BETWEEN：前者按物理偏移定位，后者需逐行比较值，I/O 和 CPU 开销都更高
• 明确限制范围：比如移动平均用 ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING，比全分区 UNBOUNDED 快一个数量级
• 累计求和场景下，若只需最新 N 条，先用 WHERE 过滤时间范围，再开窗——别在十亿行上直接套 SUM() OVER (ORDER BY ts ROWS UNBOUNDED PRECEDING)

分布式数据库里，PARTITION BY 必须对齐分片键

这是最容易被忽略、但后果最严重的点。只要 PARTITION BY 字段 ≠ 分片键，窗口计算就大概率退化为单点执行。

• 确认当前表的分片键（如 order_id % 1024），把 PARTITION BY 改成它，哪怕语义稍弱——强一致性比慢查询更难兜底
• 即使分片键一致，也要确保各 DN 内部有序：为 (shard_key, sort_col) 建联合索引，否则 CN 仍要全局重排
• TiDB/PolarDB-X 可加 /*+ SHARDING_HINT */ 提示，防止优化器误判跨分片依赖

复杂点在于：索引、分片、执行计划三者必须咬合。少一个环节，优化就失效。很多人调了 work_mem 或写了 CTE，却没改索引顺序，结果毫无改善。