MySQL 8.4 窗口函数 RANGE 和 ROWS 怎么选：同分值累计与滑动窗口边界

报表里有一列“累计销售额”，同一天的两笔订单金额相同，结果却一起跳高；换成最近 7 天平均后，又发现边界日期时多算了一行。问题通常不在 SUM() 或 AVG()，而在窗口函数到底按“行的位置”还是按“排序值的范围”取数据。

先把同一组订单放进测试数据

先用一张足够小的临时表复现问题。这里故意安排两笔金额为 100 的订单，并让它们出现在连续排序位置；如果只用不重复的金额，RANGE 与 ROWS 的差异很难被看见。

CREATE TEMPORARY TABLE sale_daily (
  id INT PRIMARY KEY,
  sold_on DATE NOT NULL,
  amount DECIMAL(10, 2) NOT NULL
);

INSERT INTO sale_daily (id, sold_on, amount) VALUES
(1, '2026-08-18', 80.00),
(2, '2026-08-18', 100.00),
(3, '2026-08-18', 100.00),
(4, '2026-08-18', 160.00);

查询时给金额补上唯一的 id 作为第二排序键，先观察明确的逐行累计，再切换到只有金额的排序条件。

RANGE 和 ROWS 的差别藏在 CURRENT ROW

下面两列都从分区起点累计到当前行，但 frame 单位不同。ROWS 把当前行理解成一个位置；RANGE 把当前行理解成排序值相同的 peers。

SELECT
  id,
  amount,
  SUM(amount) OVER (
    ORDER BY amount, id
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS rows_total,
  SUM(amount) OVER (
    ORDER BY amount
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS range_total
FROM sale_daily
ORDER BY amount, id;

结果可以按下面的方式阅读：

这也是很多“累计值突然跳两次”的根源：默认 frame 并不是逐行的 ROWS。MySQL 8.4 文档说明，带 ORDER BY 且没有显式 frame 时，默认值等价于 RANGE 从分区开头到当前行，并包含当前排序值的 peers。

时间滑动窗口要先确认业务边界

最近 7 天平均不是“前 7 行平均”。一天可能有 1 笔，也可能有几千笔；如果数据量变化，按行取数会让指标的时间跨度跟着漂移。

对于按时间值计算的范围，可以使用 RANGE 和时间间隔。下面的查询计算当天及此前 6 天内的销售额：

SELECT
  sold_on,
  SUM(amount) AS day_amount,
  AVG(SUM(amount)) OVER (
    ORDER BY sold_on
    RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW
  ) AS seven_day_avg
FROM sale_daily
GROUP BY sold_on
ORDER BY sold_on;

这里先按天聚合，再做窗口计算，避免一天多行时让同一个日期重复占用窗口位置。RANGE 的时间偏移需要匹配时间类型的 ORDER BY 表达式；把日期转成不连续的业务序号后，窗口含义就不再是自然日范围。

三个核对动作能避免窗口结果误读

核对一：排序键是否真的表达了业务顺序

需要逐行排名、逐条累计或前后行差值时，使用 ROWS 并让 ORDER BY 尽可能稳定。若只按非唯一时间排序，数据库可以把相同时间戳的行排成不同顺序，结果解释会变得困难。

核对二：同值记录应该一起结算还是逐条结算

同一价格档、同一日期或同一分数需要同时进入结果时，RANGE 更贴合“值域”的语义；流水账、游标位置和逐行余额则更适合 ROWS。

核对三：不要把排名函数的 frame 当成聚合函数的 frame

ROW_NUMBER()、RANK()、DENSE_RANK()、LAG() 和 LEAD() 等函数并不依赖当前 frame 来决定结果。给它们补上 frame 不会让排名变成“窗口内排名”，真正改变逻辑的是分区和排序条件。

常见坑：默认窗口、NULL 和不支持的语法

排查窗口结果时，先把 frame 写完整，再逐项删减。只写 ORDER BY sold_on 容易把默认 RANGE 当作逐行累计；排序列为 NULL 时，范围边界也需要单独测试；MySQL 8.4 只支持 ROWS 和 RANGE，GROUPS 与 EXCLUDE 不能直接使用。

-- 适合逐行余额或逐行累计
SUM(amount) OVER (
  PARTITION BY account_id
  ORDER BY happened_at, id
  ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)

-- 适合按连续时间值定义范围
AVG(day_amount) OVER (
  ORDER BY sold_on
  RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW
)

常见问题

RANGE 能不能替代所有的 ROWS？

不能。RANGE 的边界是排序值范围，适合同值合并或时间区间；逐条流水、明确的前 N 行和后 N 行，应使用 ROWS。

为什么默认窗口会让两条相同金额的记录结果一样？

因为带 ORDER BY 的默认 frame 等价于 RANGE 到 CURRENT ROW，当前行的同值 peers 会一起进入 frame。要逐行推进，请显式写 ROWS。

7 天平均应该用前 7 行还是 INTERVAL 6 DAY？

如果业务定义是自然日，先按天聚合，再用 RANGE 的 INTERVAL 6 DAY；只有每行严格代表一天且不允许缺天时，前 7 行才可能表达同一个意思。

MySQL 8.4 支持 GROUPS frame 吗？

不支持。文档列出的可用 frame 单位是 ROWS 和 RANGE，GROUPS 虽然能被解析，但会产生错误。

把 frame 写成验收条件

窗口函数不是越短越好。提交 SQL 前，用一条同值数据和一段缺失日期的数据分别验证：同值是否应该同步、空档是否应该扩大时间范围、排序是否稳定。只要这些问题能用测试结果回答，RANGE 与 ROWS 的选择就不再靠记忆。