窗口函数性能瓶颈源于排序与内存不足，需通过执行计划定位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，却没改索引顺序，结果毫无改善。 
