SQL滑动窗口聚合统计教程使用ROWS BETWEEN指定范围

在数据分析里，滑动窗口聚合是个高频操作，但也是最容易踩坑的地方之一。很多人写出来的窗口函数，乍一看语法都对，跑出来的结果却和业务直觉对不上。今天，我们就来聊聊其中最核心也最微妙的一个概念：ROWS BETWEEN。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

ROWS BETWEEN 是什么，它和 RANGE BETWEEN 有什么本质区别

这二者的区别，是理解窗口函数的关键。简单来说，ROWS BETWEEN 数的是“行”，它严格按照物理行位置来划定窗口边界。而 RANGE BETWEEN 看的是“值”，它根据排序键的值来分组，相同值的行会被视为一个整体。

举个例子就明白了。假设你有一张销售表，按 order_date 排序，结果集里可能有十几行记录的日期都是同一天。这时，如果你用 RANGE BETWEEN 1 PRECEDING AND CURRENT ROW 来计算“最近两天均值”，那么所有与当前行日期相同或为前一天的记录，都会被纳入计算，窗口大小可能瞬间膨胀到几十行。但如果你用 ROWS BETWEEN 1 PRECEDING AND CURRENT ROW，它就只认物理上紧挨着的前一行，窗口大小严格可控，永远是两行。

所以，一个常见的错误现象就是：当你用 A VG(sales) OVER (ORDER BY order_date RANGE BETWEEN 1 PRECEDING AND CURRENT ROW) 想算“最近两天”的均值时，在日期密集的区域，结果会剧烈跳变。因为你算的其实是“和当前日期相同或前一天的所有订单均值”，这和你想要的“时间序列上的滑动平均”根本不是一回事。

怎么写一个可靠的“过去7天销售额滚动平均”

说到滑动平均，最经典的需求莫过于“过去7天销售额的滚动平均”。这里有个关键点：时间维度不能直接用 ORDER BY date_col 配合 ROWS。为什么？因为你的原始数据里很可能有日期缺失（比如周末没销售），直接用 ROWS BETWEEN 6 PRECEDING 会错位，导致你取到的根本不是“过去7天”，而是“过去7行”。

正确的做法，得先“补全”日期。你需要一个连续的日期序列作为骨架：

• 在 PostgreSQL 里，可以用 GENERATE_SERIES 函数轻松生成。
• 在 MySQL 8.0+ 或 SQL Server 里，可以用递归 CTE 来实现。

然后，用这个连续日期序列去左连接（LEFT JOIN）你的原始销售表，把缺失日期的销售额用 COALESCE(sales, 0) 补为0。最后，在这个“日期连续、数据完整”的结果集上，套用窗口函数：A VG(sales) OVER (ORDER BY dt ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)。

下面是一个 PostgreSQL 的示例，思路很清晰：

SELECT dt,
       sales,
       ROUND(A VG(sales) OVER (ORDER BY dt ROWS BETWEEN 6 PRECEDING AND CURRENT ROW), 2) AS a vg_7d
FROM (
  SELECT d.dt, COALESCE(t.sales, 0) AS sales
  FROM GENERATE_SERIES('2024-01-01'::DATE, '2024-01-31'::DATE, '1 day') AS d(dt)
  LEFT JOIN sales_table t ON d.dt = t.sale_date
) AS filled;

ROWS BETWEEN 的边界参数哪些能省略，哪些绝对不能省

写窗口帧的时候，边界参数怎么省是个学问。CURRENT ROW 在某些情况下可以省略，比如 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 可以简写成 ROWS UNBOUNDED PRECEDING。但核心原则是：起始和结束边界必须成对出现，语义才完整。

有几个容易踩的坑：

• ROWS BETWEEN 2 PRECEDING —— 缺少 AND ... 来指定结束边界，语法直接报错。
• ROWS BETWEEN 1 FOLLOWING AND 1 PRECEDING —— 起始边界在结束边界之后，逻辑矛盾。PostgreSQL 会报错，而 MySQL 可能会静默地返回空值，更隐蔽。
• ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING —— 这种“前后各N行”的写法在首尾几行会自动截断，实际参与计算的行数会少于11行，这是符合预期的，但心里要有数。

性能影响：ROWS 越宽，执行计划越容易崩

最后，我们来谈谈性能。窗口帧的宽度，直接决定了内存占用和排序开销。当你写下 ROWS BETWEEN 10000 PRECEDING AND CURRENT ROW 这样的语句，面对百万级的结果集时，数据库引擎的压力是巨大的。PostgreSQL 可能会因为 work_mem 不足而被迫降级到磁盘排序，速度骤降；SQL Server 甚至可能直接拒绝执行，抛出一个“查询处理器无法生成查询计划”的错误。

这里有几个优化建议：

• 避免无意义的大数字：如果你本意是想取“所有前面的行”，那就直接用 UNBOUNDED PRECEDING，别写一个巨大的具体数字，这会让优化器很难做。
• 利用索引：在 ORDER BY 的字段上建立索引，能让窗口计算复用排序结果，大幅降低 CPU 和内存的压力。
• 考虑替代方案：如果只是求一个简单的累计值（比如 running sum），并且数据本身就是按时间顺序入库的，有时候用应用层的流式累加来代替数据库的窗口函数，可能是更轻量、更高效的选择。

说到底，ROWS BETWEEN 的语法本身并不复杂。真正的挑战，是当它遇上稀疏的时间序列、超高基数的分组、或者超长的滑动跨度时，如何确保结果既正确无误，又能高效执行。这时候，与其盲目调大数据库的内存参数，不如回过头，好好审视一下你的数据分布和物化策略。这才是解决问题的根本。