窗口函数性能瓶颈主因是分区粒度不当、排序不稳定、窗口范围过大及未预过滤数据；须在子查询中用where提前筛选、选高基数稳定字段分区、order by补唯一字段、优先用rows而非range。
窗口函数在大数据表里跑不动，不是它不行，而是你没给它“减负”——核心问题从来不是函数本身，而是分区粒度、排序稳定性、窗口范围和数据预过滤这四件事没做对。
WHERE 条件必须写在窗口外层子查询里
全表扫完再开窗，等于把几千万行全塞进内存排序。哪怕只是加个时间范围，也得在 OVER 之前就筛干净。
- 错误写法：
SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) rn FROM orders→ 触发全表扫描 + 全表排序 - 正确写法：
SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) rn FROM (SELECT id, user_id, created_at FROM orders WHERE status = 'shipped' AND created_at >= '2026-04-01') t - WHERE 字段最好命中复合索引前缀，比如
(status, created_at)，让子查询走range扫描而非ALL - 别指望引擎自动下推：MySQL 8.0、Spark SQL 都不保证
WHERE会自动下推到窗口子查询里
PARTITION BY 字段选错是性能崩盘主因
用 user_id 分区在亿级日志表里，基本等于自找 spill；换成 date_trunc('day', event_time) 或 tenant_id 就秒出——关键看基数是否高、分布是否稳。
- 优先选高基数 + 业务语义稳定字段，如
tenant_id、shop_id，避免user_id这类倾斜字段 - 如果必须按
user_id计算，先预聚合：按天汇总用户行为，再在小表上开窗 - 检查执行计划里
WindowAgg节点的rows和width：单分区超 100 万行就开始减速，超 500 万基本 spill - Spark 中
PARTITION BY错误会导致所有数据 shuffle 到单个 Executor，Shuffle 数据量可能从 12GB 暴涨到 98GB
ORDER BY 必须补唯一字段防非确定性
ORDER BY created_at 在精度只到秒的场景下，几百行可能共享同一时间戳，窗口函数就会随机取“前几行”，结果每次都不一样——这不是 bug，是设计使然。
- 只要
ORDER BY字段存在重复值，就必须补一个唯一字段，例如ORDER BY created_at, id -
ROW_NUMBER()、LAG()、累计求和都依赖这个顺序；没它，ROWS BETWEEN 2 PRECEDING AND CURRENT ROW就失去意义 - 外层
ORDER BY不影响窗口计算逻辑，只控制最终输出顺序；想让rn = 1是首单，就得靠窗口里的ORDER BY - Hive/Trino 中缺失或模糊的
ORDER BY会导致ROW_NUMBER()结果不可复现
ROWS BETWEEN 比 RANGE BETWEEN 更可控
RANGE BETWEEN INTERVAL '7 days' PRECEDING 看着直观，但遇到日期稀疏或大量重复值时，实际窗口可能卷入几千行，直接 OOM；ROWS BETWEEN 6 PRECEDING AND CURRENT ROW 才是真·七日滚动。
-
ROWS按物理行偏移，快且确定；RANGE按排序值范围匹配，语义模糊、跨库行为不一致（PostgreSQL 支持，PrestoDB 可能报错） - 时间类滑动窗口，优先用
ROWS+ 子查询预处理成连续序列，或用GENERATE_SERIES补齐空缺 - MySQL 8.0 对大
RANGE窗口仍会落磁盘，而 PostgreSQL 14+、ClickHouse 对ROWS有高效实现 - 没显式写
ROWS BETWEEN时，默认是UNBOUNDED PRECEDING，移动平均这类场景务必显式限定范围
最常被忽略的点：窗口函数不是万能加速器，它只是把计算逻辑压进一次扫描里——前提是数据已经足够轻。真正卡住的时候，90% 的问题不在 OVER 里，而在它外面那层 WHERE 和 PARTITION BY 的选择上。
