窗口函数溢出源于中间结果集过大或数据类型溢出，应先where过滤再开窗、显式cast为bigint、order by加唯一列、用rows而非range、避免select *。
窗口函数本身不溢出，溢出来自两件事：中间结果集太大、累计计算时数据类型撑爆。关键不是“少用窗口函数”，而是控制它算什么、怎么算、在哪算。
先WHERE过滤再开窗，别让窗口函数面对全表
窗口函数无法下推WHERE条件，但你可以把它包进子查询里。数据库执行顺序是：FROM → WHERE → GROUP BY → 窗口函数 → ORDER BY → LIMIT。窗口永远在WHERE之后运行，所以必须手动前置过滤。
- 错误写法：
SELECT *, SUM(amount) OVER (ORDER BY created_at) FROM orders→ 全表扫描 + 全表排序 + 全表累计 - 正确写法：
SELECT *, SUM(amount) OVER (ORDER BY created_at) FROM (SELECT id, amount, created_at FROM orders WHERE status = 'completed' AND created_at >= '2026-01-01') t - WHERE条件尽量命中复合索引前缀，比如
INDEX(status, created_at)，让子查询走range扫描而非ALL
显式CAST输入列为BIGINT，防止INT累加溢出
SUM() OVER的中间计算类型由输入列决定。如果amount是INT，哪怕最终结果没超限，中间累计过程也可能在第10万行就触发integer out of range（PostgreSQL）或截断（MySQL 5.7+默认报错）。
- 必须写成：
SUM(CAST(amount AS BIGINT)) OVER (ORDER BY created_at, id) - 别写成：
CAST(SUM(amount) AS BIGINT) OVER (...)——溢出已经发生在SUM内部 - 如果表达式含常量（如
amount + 1），也要一并转：CAST(amount AS BIGINT) + CAST(1 AS BIGINT)
ORDER BY必须带唯一性列，避免排序不确定性导致重复累计
不写ORDER BY时，SUM() OVER ()是全表总和；写了但字段值重复（比如多个订单同秒创建），不同数据库行为不一致：PostgreSQL可能乱序，SQL Server直接报错。累计值会因行序漂移而不可靠。
- 永远显式写
ORDER BY created_at, id，id确保每行唯一 - 别依赖主键隐式顺序——优化器可能重排，尤其在有JOIN或复杂WHERE时
- 确保
(created_at, id)有索引，否则排序阶段必然触发Sort Method: external merge Disk（PostgreSQL）或Sort_merge_passes飙升（MySQL）
慎用RANGE，优先用ROWS或默认帧
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW看着自然，但实际会把所有相同created_at的行合并进同一窗口帧，导致累计值“跳变”，且无法利用索引加速。多数数据库对RANGE窗口的优化极弱。
- 用
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（这是默认行为，可省略） - 避免
RANGE，除非业务明确要求按值区间聚合（如“当天所有订单累计”） - 在PostgreSQL中，若数据超千万行且
EXPLAIN ANALYZE显示WindowAgg节点耗时占比>70%，考虑用LATERAL JOIN+ 子查询分段替代
最易被忽略的一点：窗口函数的内存压力不只来自行数，更来自每行的数据宽度。SELECT * + 大TEXT/BLOB字段 + 窗口函数，等于主动申请磁盘溢写。始终只取必要字段，尤其是做累计求和这种纯数值场景。
