MySQL window frame 怎样区分 ROWS 和 RANGE 窗口

MySQL 的窗口帧不是“两个都能表示前几条数据”的同义写法。ROWS 按当前行在排序结果中的位置计算，RANGE 按排序表达式的值计算；当多行拥有相同排序值时，RANGE 会把这些 peer 行视为同一组。需要逐条累加时通常选 ROWS，需要把同一数值或时间点的记录一起纳入时才选 RANGE。

MySQL 官方地址：https://dev.mysql.com/doc/refman/8.4/en/window-functions-frames.html

判断方法很简单：先问自己“窗口边界要跟着第几行移动，还是跟着排序值移动”。前者写 ROWS，后者写 RANGE；如果排序键可能重复，最好显式写出 frame，不要依赖默认值。

先看排序键是否存在并列值

窗口函数先在每个分区内按 ORDER BY 排序，再根据 frame 取出当前行可见的记录。ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 的终点是当前这一行；RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 的终点则包含当前排序值对应的全部 peer 行。

-- 建立一组故意存在相同日期的数据，便于观察 peer 行
WITH sales AS (
  SELECT 1 AS id, '2026-10-01' AS sold_on, 10 AS amount
  UNION ALL SELECT 2, '2026-10-01', 20
  UNION ALL SELECT 3, '2026-10-02', 15
)
SELECT id, sold_on, amount,
       -- ROWS 只把当前物理行加入累计范围
       SUM(amount) OVER (
         ORDER BY sold_on, id
         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS rows_total,
       -- RANGE 按 sold_on 的值判断边界；相同日期会成为 peer
       SUM(amount) OVER (
         ORDER BY sold_on
         RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS range_total
FROM sales
ORDER BY sold_on, id;

这个示例中，ROWS 的排序增加了 id，让每一行都有明确的位置；RANGE 只按日期排序，所以两条 2026-10-01 记录的窗口终点相同。结果上，rows_total 会逐行增长，而 range_total 会在第一条日期记录处直接包含同日期的两笔金额。

用并列日期看出两种 frame 的差异

如果业务要求“每一笔订单都显示到当前记录为止的累计金额”，应该使用 ROWS，并给排序补上稳定的唯一键。如果业务要求“统计截至当前日期的累计金额”，同一天的记录应当得到同一个日期累计值，这时 RANGE 更符合语义。

-- 逐笔累计：id 是稳定的第二排序键，当前行边界不会吞并同日期下一行
SELECT id, sold_on, amount,
       SUM(amount) OVER (
         PARTITION BY customer_id
         ORDER BY sold_on, id
         ROWS UNBOUNDED PRECEDING
       ) AS order_running_total
FROM customer_orders;

-- 按日期累计：同一天的金额共享一个日期窗口
SELECT id, sold_on, amount,
       SUM(amount) OVER (
         PARTITION BY customer_id
         ORDER BY sold_on
         RANGE UNBOUNDED PRECEDING
       ) AS date_running_total
FROM customer_orders;

两段查询的区别不在聚合函数，而在“当前行”的定义。ROWS 关心行号距离，例如 ROWS BETWEEN 2 PRECEDING AND CURRENT ROW 表示当前行加前两行；RANGE 关心排序值距离，例如数值排序时可以写 RANGE BETWEEN 10 PRECEDING AND CURRENT ROW，把当前值往前 10 的范围纳入计算。

不要忽略带 ORDER BY 时的默认 frame

没有写 frame 时，MySQL 在存在窗口 ORDER BY 的情况下默认采用从分区开始到当前行 peer 的范围，等价于 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。因此，下面的写法并不是逐行累计：

-- 未显式写 frame，默认会按 RANGE 处理当前排序值的 peer
SELECT id, sold_on, amount,
       SUM(amount) OVER (ORDER BY sold_on) AS implicit_total
FROM customer_orders;

-- 需要逐条累计时，把 frame 写清楚，并用 id 打破同日期并列
SELECT id, sold_on, amount,
       SUM(amount) OVER (
         ORDER BY sold_on, id
         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
       ) AS explicit_total
FROM customer_orders;

如果窗口定义没有 ORDER BY，默认范围是整个分区。这个默认行为在简单数据上不明显，直到报表出现重复日期、相同价格或相同分数，累计值才会看起来“跳了一步”。所以涉及财务流水、库存变动或序号累计时，显式写 ROWS 往往更容易维护。

按业务目标选择 ROWS 还是 RANGE

还要注意，MySQL 8.4 支持的 frame 单位是 ROWS 和 RANGE；不要把其他数据库中的 GROUPS 或 EXCLUDE 语法直接搬过来。排查结果异常时，先把窗口的 PARTITION BY、ORDER BY、frame 起止点和重复排序值列出来，通常比盲目修改聚合函数更快定位原因。

相关问题

ROWS 一定比 RANGE 快吗？

不能只凭关键字判断性能。实际代价还取决于分区大小、排序、数据分布和查询计划；应先明确语义，再结合执行计划和真实数据评估。

只有一个 ORDER BY 字段时应该怎么办？

如果要逐条处理，补充一个稳定且唯一的排序键，并明确写 ROWS。如果同值记录本来就应该共享结果，则保留值排序并选择 RANGE。

为什么默认累计值会突然增加两笔？

常见原因是默认 frame 按 RANGE 包含了当前排序值的所有 peer。把目标改成逐行累计时，显式指定 ROWS 并补充唯一排序键。