窗口函数内存溢出根源在于执行路径未拦截全量数据，必须先通过where/cte过滤缩小输入集，再建partition by与order by匹配的复合索引，并避免大分区累计计算。
窗口函数内存溢出不是配置调得小，而是执行路径没拦住全量数据——只要看到 WindowAgg 节点下挂的是全表扫描或未命中索引的扫描，基本就坐实了问题根源。
看执行计划里有没有 WindowAgg 和 Sort 套娃
PostgreSQL 的 EXPLAIN (ANALYZE) 中，如果最外层是 WindowAgg，子节点是 Seq Scan 或 Index Scan 但 Actual Rows 高达百万/千万级，同时出现 Sort Method: external merge Disk，说明排序已冲出内存；MySQL 则重点看 Extra 字段是否含 Using filesort，再结合 SHOW STATUS LIKE 'Sort_merge_passes' 持续上涨确认。
- 别只盯
cost估值，Actual Time和Actual Rows才是真实负载 -
WindowAgg节点本身不带过滤能力，它前面的节点决定了喂给它的数据量 - 如果子节点用了
Bitmap Heap Scan+Bitmap Index Scan，大概率是 WHERE 条件没走索引，优化器被迫回表捞全量
检查 PARTITION BY 和 ORDER BY 字段有没有对应索引
窗口函数要求先按 PARTITION BY 分区、再在每个分区内按 ORDER BY 排序。数据库无法“边读边算”，必须把整个分区的数据加载进内存排序——哪怕你最后只取 ROW_NUMBER() = 1。
- 复合索引顺序必须匹配：比如
PARTITION BY user_id ORDER BY created_at DESC，索引应建为(user_id, created_at)，而非(created_at, user_id) - WHERE 过滤字段如果和分区/排序字段无关（例如只加
WHERE status = 'shipped'但没包含在索引中），索引可能失效 - PostgreSQL 对
DESC排序支持良好，但 MySQL 8.0 前对混合升/降序索引支持有限，慎用ORDER BY a ASC, b DESC
确认过滤逻辑有没有下推到子查询或 CTE 里
窗口函数不能被 WHERE 下推，WHERE rn = 1 这种写法会直接报错；想减少输入数据量，唯一可靠方式是把过滤提前到窗口计算之前。
- 错误写法：
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) rn FROM orders WHERE status = 'shipped'→ 过滤发生在窗口之后，无效 - 正确写法：
SELECT * FROM (SELECT user_id, created_at FROM orders WHERE status = 'shipped' AND created_at >= '2026-01-01') t WINDOW w AS (PARTITION BY user_id ORDER BY created_at DESC) - 如果业务允许时间范围裁剪，
created_at >= '2026-04-01'这类条件比单纯status更容易命中索引范围扫描
警惕那些“不得不做大分区”的场景
像用户全生命周期流水求 SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，单个活跃用户可能有上万笔订单——这种不是加个索引就能解决的，得从业务侧找妥协点。
- 拆时间粒度：改用日级/周级汇总表替代原始明细流
- 接受近似结果：用
APPROX_COUNT_DISTINCT或采样窗口（如 PostgreSQL 的TABLESAMPLE）预估趋势 - 物化中间状态：把 running_total 存成每日快照，用增量更新代替实时计算
真正难处理的，从来不是语法写错，而是业务需求和数据库执行模型之间的硬冲突——窗口函数天生要“见全部才敢算”，而大数据量下，“全部”本身就是个危险词。
