窗口函数慢主因是partition by设计不当，如高基数或低基数字段导致分区爆炸或退化，加order by强制排序、过滤未前置、窗口未复用等加剧性能问题。
窗口函数慢，八成是 PARTITION BY 选错了
不是窗口函数本身慢，而是分区键设计不合理，让数据库反复做无效扫描或排序。比如用 user_id 分区查亿级日志表，实际会生成上千万个极小分区，每个都要初始化上下文、分配内存、维护状态——CPU 和内存开销陡增。
容易踩的坑：
-
PARTITION BY字段无索引，又带ORDER BY，执行计划里必出Seq Scan+Sort - 用低基数字段（如
status只有 'active'/'inactive'）分区，95% 数据挤进一个分区，退化成全局计算 - 误以为“越细越好”，拿毫秒级
created_at或uuid当分区键，分区数爆炸
实操建议：
- 优先选业务语义明确、基数适中（几千～几万）、且已有索引的字段，如
region_id、product_category - 必要时降维：把
created_at转成DATE(created_at)再分区 - 用
EXPLAIN (ANALYZE)看WindowAgg节点的Partitions数量，超 10 万就得调
ORDER BY 在窗口里不是“排结果”，而是强制排序
写了 ORDER BY 就意味着数据库必须为每个分区单独排序——哪怕底层数据已按该列物理有序，绝大多数引擎（PostgreSQL/MySQL 8.0+/SQL Server）仍会执行显式排序，除非满足极苛刻条件（联合索引完全匹配 + 无 FILTER + 无计算列）。
常见错误现象：
- 加了
CREATE INDEX idx_user_time ON orders(user_id, order_time)，但查询仍慢；原因可能是ORDER BY UPPER(name)或FILTER (WHERE amount > 0)，直接废掉索引复用 - 用
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，遇到重复时间值时反复回查，IO 暴涨
实操建议：
- 只在真需要序逻辑时加
ORDER BY；纯计数用COUNT(*) OVER (PARTITION BY x)就够了 - 排序列必须有索引，且复合索引顺序要和
PARTITION BY+ORDER BY严格一致 - 避免
RANGE帧，改用ROWS并补唯一字段：如ORDER BY order_time, id
别让窗口函数扫全表：过滤必须前置
最常被忽略的性能杀手：把强过滤条件（如时间范围、状态码）放在外层 WHERE，而窗口函数套在内层子查询或 CTE 上——此时窗口计算已在百万/千万行上完成，浪费严重。
使用场景：
- 报表只看近 30 天数据，但 SQL 写成
SELECT ..., ROW_NUMBER() OVER (...) FROM orders WHERE order_date >= ...→ 错！WHERE在窗口之后 - 想取每个租户最新 3 条订单，却先开窗再
LIMIT→ 全量排序后再裁剪，毫无意义
实操建议：
- 过滤条件一律塞进最内层：CTE、子查询或物化临时表
- 高频固定范围（如按天/按周）可预建分区表或物化视图，避免每次重算
- 若需 Top-N，优先用
QUALIFY（Snowflake/BigQuery）或子查询LIMIT，别靠窗口函数硬排
窗口复用和中间结果物化比“写得短”更重要
同一个窗口定义（如 PARTITION BY region ORDER BY sale_date）如果在 SELECT 列表里出现三次，旧版 PostgreSQL 或 MySQL 8.0 可能真会算三遍：三次分区、三次排序、三次内存缓存。
性能影响：
- 单次窗口计算耗时 2s，三个同逻辑表达式就变成 6s，还可能触发多次磁盘 spill
- 宽表+JSON/TEXT 字段参与分区，内存占用翻倍，
work_mem不够直接落盘
实操建议：
- 统一用
WINDOW w AS (PARTITION BY x ORDER BY y)定义，所有地方复用OVER w - 多个窗口函数共用同一分区逻辑时，先用 CTE 物化中间结果（
WITH filtered AS (...), windowed AS (SELECT ..., ROW_NUMBER() OVER w, SUM() OVER w FROM filtered)） - 对低频更新、高频查询的报表，直接写入带窗口结果的宽表，绕过实时计算
