MySQL 窗口帧怎样计算按日期的累计值

做日报累计时，最容易忽略的不是 SUM()，而是窗口帧到底按“行的位置”还是按“日期的值”取数据。MySQL 在窗口里写了 ORDER BY order_date 后，省略帧定义时默认采用 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW；同一天的多条记录会被当成 peers 一起纳入当前帧。

如果业务要“同一天的订单一起算”，使用默认 RANGE 或显式 RANGE；如果业务要“每一行逐笔递增”，使用 ROWS，并为同一天补充唯一排序键。

下面用订单表做一组对比。示例只围绕日期累计，不把窗口函数扩展成排名、分页或其他用法。

先固定业务粒度和排序键

假设 orders 每行是一笔订单，字段如下：

• customer_id：客户或租户标识，用于分区；
• order_date：业务日期，作为累计的主要时间键；
• order_id：订单唯一编号，用于同一天内稳定排序；
• amount：订单金额，作为累计指标。

这几个字段的关系可以先抽象成下面这张静态图。分区决定“谁和谁一起算”，排序键决定当前行的时间位置，窗口帧决定累计范围。

如果一行不是订单，而是每天已经汇总好的日报，那么 order_date 通常天然唯一；如果一行仍是明细，就必须先决定同一天的订单应该并列显示，还是逐笔显示。

用默认窗口得到按日期累计

“从分组第一天累计到当前日期，并让同一天显示同一个累计值”是 RANGE 更自然的场景：

SELECT
    customer_id,
    order_date,
    order_id,
    amount,
    SUM(amount) OVER (
        PARTITION BY customer_id
        ORDER BY order_date
    ) AS running_total
FROM orders
ORDER BY customer_id, order_date, order_id;
-- 省略 frame 时，ORDER BY 存在时默认按 RANGE 到当前日期。
-- 最外层排序只负责展示顺序，不改变窗口内部的累计口径。

MySQL 官方文档说明，带 ORDER BY 且省略帧时，默认帧等价于从分区起点到当前行 peers 的 RANGE。因此同一客户在同一天有两笔订单时，两笔结果会同时包含这一天的全部金额。

例如某客户的金额为 100、80、60，前两笔发生在 10 月 1 日，第三笔发生在 10 月 2 日，按日期累计的说明结果是：

这里的“同一天一起到达”不是重复计算，而是当前日期的 peers 共同属于当前帧。它适合日报、按天结算和按自然日看趋势的报表。

用 ROWS 区分实际行位置

如果页面要展示逐笔订单流水，用户往往希望每新增一行就增加这一行的金额。此时显式使用 ROWS：

SELECT
    customer_id,
    order_date,
    order_id,
    amount,
    SUM(amount) OVER (
        PARTITION BY customer_id
        ORDER BY order_date, order_id
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_total
FROM orders
ORDER BY customer_id, order_date, order_id;
-- ROWS 按行位置取帧，所以同一天的两笔订单会分别增加。
-- order_id 让同一天的顺序稳定，避免展示结果依赖非唯一日期排序。

同一组数据在 ROWS 下可理解为 100、180、240。注意，只有把唯一的 order_id 加入窗口排序，逐笔顺序才有清晰的业务含义；只写 ORDER BY order_date 时，同一天内部谁先谁后并不应该被当成可靠规则。

两种语义的差异如下：

用 RANGE INTERVAL 表达日期范围

“累计到今天”与“最近七天合计”不是一个窗口。后者要表达日期值的范围，可以给 RANGE 使用时间间隔：

SELECT
    customer_id,
    order_date,
    SUM(amount) OVER (
        PARTITION BY customer_id
        ORDER BY order_date
        RANGE BETWEEN INTERVAL 6 DAY PRECEDING AND CURRENT ROW
    ) AS seven_day_total
FROM daily_orders
ORDER BY customer_id, order_date;
-- 6 DAY 加当前日期组成最近 7 个自然日窗口。
-- daily_orders 最好是一行一天；明细表则会让同日期记录作为 peers 一起纳入。

日期型 RANGE 需要日期或时间表达式作为排序键。它按日期值计算范围，不要求中间每一天都有数据：如果某天没有订单，那天没有输出行，但之后出现的日期仍会按实际日期差判断窗口。这个方案适合日报表和滚动指标，不适合表达“最近 7 笔订单”。

如果需求是最近 7 行，而不是最近 7 天，则应该改成 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW。二者看起来都写了 6，但一个数行，一个数日期范围，不能只看数字决定方案。

按业务口径选择并检查边界

可以按下面的清单落地：

1. 先问清楚“一行”代表订单明细还是日期汇总；
2. 需要同日期结果相同，就用 RANGE，并接受 peers 同时纳入；
3. 需要逐笔结果，就用 ROWS，并补充 order_id 等唯一排序键；
4. 需要最近 N 天，就用日期型 RANGE INTERVAL，不要用 N 行替代；
5. 需要客户、门店或租户分别累计，就把边界字段放进 PARTITION BY；
6. 确认金额的 NULL 处理和数据类型，避免把缺失金额误当成业务上的零。

最后提醒一个容易被忽视的点：外层的 ORDER BY 只控制结果展示，窗口内部的 ORDER BY 才决定帧如何移动。把两者写成同样的排序通常更易读，但不能因此省略窗口中的排序键。

常见问题

为什么同一天两行的默认累计值相同？

因为默认帧是 RANGE，当前日期的 peers 会共同进入当前帧。要逐行增加，改用 ROWS 并提供稳定的第二排序键。

ROWS BETWEEN 6 PRECEDING 是最近七天吗？

不是，它是当前行加前 6 行，表示最近 7 行。日期不连续或一天多行时，它与最近 7 个自然日会产生不同结果。

只按日期排序时能否指定同一天的先后？

不能把非唯一日期当成可靠的行序。若业务关心逐笔先后，应使用订单编号、创建时间加唯一编号等可复现的组合排序键。

总结

按日期累计的关键不是把 SUM 写进 OVER，而是先选择帧语义：自然日累计用 RANGE，逐笔累计用 ROWS，最近若干自然日则使用带 INTERVAL 的日期型 RANGE。把分区、排序键和帧边界一起写清楚，报表结果才不会因同一天多行而悄悄改变。