MySQL 窗口函数怎样计算每组累计金额

如果报表既要展示每一笔订单，又要看到“这个客户截至当前订单一共花了多少”，单独使用 GROUP BY 会把明细压成一行。更合适的写法是把 SUM(amount) 放进窗口函数：用 PARTITION BY customer_id 划分客户，用窗口内的 ORDER BY paid_at, order_id 确定累计顺序。这样每条订单仍然保留，累计金额只是新增的一列。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/window-functions.html

先把“每组”和“累计到哪一行”说清楚

本文假设有一张订单明细表，每行代表一笔已支付订单：

-- amount 使用定点数，避免金额计算依赖浮点近似。
CREATE TABLE customer_orders (
    order_id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    paid_at DATETIME NOT NULL,
    amount DECIMAL(12, 2) NOT NULL
);

累计金额其实包含两个判断：第一，哪些行属于同一组；第二，当前行之前的哪些行应该被加进来。窗口函数不会像普通聚合那样把一组压成一行，而是为每个当前行计算一次结果。

可以把它记成一个简单模板：

-- PARTITION BY 决定分组，ORDER BY 决定组内累计方向。
SUM(amount) OVER (
    PARTITION BY customer_id
    ORDER BY paid_at, order_id
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)

最小写法：每个客户各自累计

查询时把累计表达式放到明细列旁边即可：

-- 每个客户从最早支付的订单开始，逐行累加金额。
SELECT
    order_id,
    customer_id,
    paid_at,
    amount,
    SUM(amount) OVER (
        PARTITION BY customer_id
        ORDER BY paid_at, order_id
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_amount
FROM customer_orders
ORDER BY customer_id, paid_at, order_id;

这里的 PARTITION BY customer_id 让客户之间互不串账；UNBOUNDED PRECEDING 表示从本客户分区的第一行开始，CURRENT ROW 表示累计到当前行。假设某客户金额依次为 80、120、50，新增列就是 80、200、250；另一客户会从自己的第一笔金额重新开始。

这和下面的分组汇总不是同一件事：

-- GROUP BY 只返回每个客户一行，不能直接保留每笔订单。
SELECT customer_id, SUM(amount) AS customer_total
FROM customer_orders
GROUP BY customer_id;

需要“客户总额”时用 GROUP BY；需要“每笔订单在客户累计中的位置”时用窗口函数。窗口函数的结果列可以和订单号、金额、支付时间同时返回。

支付时间相同，为什么还要加 order_id

真实订单经常只精确到秒，甚至同一批导入的记录拥有相同的 paid_at。如果窗口内只写 ORDER BY paid_at，相同时间值属于同一排序值，行与行之间的先后就没有被完整表达。页面可能仍然显示结果，但累计顺序不适合作为稳定的业务规则。

把唯一键或能够确定业务顺序的字段追加进去：

-- paid_at 相同的时候，用 order_id 作为确定性的第二排序键。
SELECT
    order_id,
    customer_id,
    paid_at,
    amount,
    SUM(amount) OVER (
        PARTITION BY customer_id
        ORDER BY paid_at ASC, order_id ASC
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_amount
FROM customer_orders
ORDER BY customer_id, paid_at ASC, order_id ASC;

这里有两个 ORDER BY：窗口定义中的排序控制“怎么累计”，查询末尾的排序控制“结果怎么展示”。把末尾的排序删掉，并不代表累计公式错误；只是返回行的展示顺序不再由查询明确规定。

重复排序值时，什么时候显式写 ROWS

为了让“每一笔订单逐行增加”成为明确契约，建议在累计场景直接写出 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。它按排序后的物理行定义当前帧，当前行之前的行和当前行进入累计范围。

如果只写 SUM(amount) OVER (PARTITION BY customer_id ORDER BY paid_at)，就把窗口帧的默认行为交给数据库语义。尤其在 paid_at 重复时，同一个排序值的 peer 行可能被视为同一组处理，这和“每行一步”的业务阅读方式不一定一致。使用唯一的复合排序键再配合显式 ROWS，累计结果更容易解释和复查。

如果业务要的是“同一支付时间视为同一批次”，那可以保留相同时间的 peer 语义；这时重点不是机械套用 ROWS，而是先确认产品定义的是逐订单累计，还是按时间批次累计。窗口帧选择必须跟业务口径一致。

结果过滤要再包一层查询

窗口函数只能出现在查询的选择列表和顶层 ORDER BY 中，不能直接在同一层 WHERE 里引用别名 running_amount。如果要找“累计金额达到 1000 之后的订单”，先计算，再在外层过滤：

-- 先在内层得到累计列，外层再按累计结果筛选。
SELECT *
FROM (
    SELECT
        order_id,
        customer_id,
        paid_at,
        amount,
        SUM(amount) OVER (
            PARTITION BY customer_id
            ORDER BY paid_at, order_id
            ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        ) AS running_amount
    FROM customer_orders
) AS ordered_amounts
WHERE running_amount >= 1000
ORDER BY customer_id, paid_at, order_id;

外层过滤会改变最终留下的行，但不会改变内层窗口计算的累计范围。若先用 WHERE 去掉部分订单再计算，累计自然只针对筛选后的数据；这可能是需求，也可能是误删了历史明细，需要先确认筛选条件属于累计前还是累计后。

一张表记住窗口累计的选择

最后可以按四个问题复查 SQL：客户边界是不是 PARTITION BY 表达的；累计方向是否有完整排序键；重复排序值时帧是否符合业务；页面展示顺序是否在最外层明确写出。只要这四点分开，窗口函数就不会和普通分组混在一起。

相关问题：

• 如何计算每个客户最近 30 天内的累计金额？先在窗口计算前限定时间范围，再决定是否需要保留范围外基线。
• 累计金额要从大到小倒序吗？可以把窗口内排序写成 DESC，但必须同时调整业务对“当前”的定义。
• 为什么累计结果和页面顺序不一致？检查窗口内的 ORDER BY 与查询末尾的 ORDER BY 是否分别满足计算和展示要求。
• 金额字段应使用什么类型？金额通常使用定点数类型，并按业务规则处理精度与舍入。

本文示例围绕 MySQL 8.4 窗口函数官方语义组织，查询为原创示例，读者应结合自己的表结构、时间精度和金额规则调整。