窗口函数性能开销主要来自分区和排序：分区触发重分布，无索引时内存占用上升；排序为O(n log n)每分区，键匹配联合索引可避免。优化需建最左前缀索引、慎用窗口、预计算及监控执行计划。
窗口函数的性能开销主要来自 分区（PARTITION BY） 和 排序（ORDER BY） 两个阶段，它们直接影响执行计划中的资源消耗和响应时间。
分区操作的实际开销
分区本身不强制排序，但会触发数据重分布（repartitioning）。数据库需按分区键对行进行分组，通常通过哈希或排序实现：
- 若分区键上有索引且统计信息准确，优化器可能复用索引顺序，避免额外排序；
- 无索引或高基数分区键时，常需构建哈希表或执行全局重哈希，内存占用明显上升；
- 分区列含 NULL 值时，不同数据库处理方式不同（如 PostgreSQL 将 NULL 视为独立组，MySQL 8.0 默认不合并 NULL），可能意外增加分区数量。
排序阶段是性能瓶颈主因
只要窗口定义中包含 ORDER BY（即使没写显式框架子句），数据库就必须为每个分区单独排序：
- 排序复杂度为 O(n log n) 每个分区，而非全表；但若分区大而多（如按用户ID分区，某大V用户占百万行），局部排序仍昂贵；
- 若分区键与排序键一致且有联合索引（如
(user_id, event_time)），可跳过排序步骤，直接流式计算； - 未指定
ROWS BETWEEN或RANGE BETWEEN时，多数引擎默认使用RANGE UNBOUNDED PRECEDING，仍需排序以确定“当前行位置”。
如何降低开销：实用建议
关键不是避免窗口函数，而是控制其执行路径：
- 优先让
PARTITION BY列和ORDER BY列组成最左前缀索引； - 能用聚合+JOIN 替代的简单场景（如求每个部门最高薪），不用窗口函数；
- 对超大分区，考虑预计算中间结果到物化视图或汇总表；
- 在 EXPLAIN 中重点观察是否出现
WindowAgg节点下的Sort或Hash子节点，及其 estimated rows 与 width 是否异常。
不复杂但容易忽略：一个没索引的 PARTITION BY user_id ORDER BY created_at 在千万级表上可能比等价的 GROUP BY 慢 5–10 倍。
