MySQL 窗口函数怎样复用相同排序

MySQL 中多个窗口函数使用完全相同的分区、排序和窗口帧时，可以把定义放入 WINDOW 子句，再让各函数通过 OVER 窗口名 引用。若只是排序相同而窗口帧不同，应保留不同统计范围，不能为了合并而改掉结果语义。

以下以 MySQL 8.4 参考手册为依据，不宣称其他版本的执行计划完全一致。官方文档入口：https://dev.mysql.com/doc/refman/8.4/en/。命名窗口语法：https://dev.mysql.com/doc/refman/8.4/en/window-functions-named-windows.html。

先把重复窗口改成一个名字

假设业务明细表 ledger_events 有账户、事件编号、发生时间和金额四个字段。报表同时要累计金额与累计平均金额。最小改动是统一为 w_running，让两个函数引用同一份定义。

-- 两个聚合窗口共享完整定义；event_id 用于同一时间内的稳定行序。
SELECT
    account_id, event_id, event_time, amount,
    SUM(amount) OVER w_running AS running_amount,
    AVG(amount) OVER w_running AS running_average
FROM ledger_events
WINDOW w_running AS (
    PARTITION BY account_id
    ORDER BY event_time, event_id
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)
ORDER BY account_id, event_time, event_id;

把 WINDOW 放在 FROM 及筛选、分组相关子句之后、最终 ORDER BY 之前。这里的名字属于当前查询块，不是创建可跨语句调用的数据库对象。示例未在本地数据库执行。

这次设计把“统计函数做什么”和“哪些行进入统计”拆开：SUM 与 AVG 各自计算，公共窗口负责定义范围。命名窗口并不是把两种函数变成一个计算结果。

让调用方明确行序与统计口径

给调用方约定报表列时，应同时写清三个维度：按 account_id 分区，按 event_time, event_id 排序，按 ROWS 从分区开头累计到当前行。假设 event_id 在账户内唯一且相关字段非空，时间重复时也能确定先后。

新增第二个排序键可能改变业务含义，不能把它当成纯性能改动。本例需要逐条事件累计；如果需求是“同一时间的事件得到同一个累计值”，应另行定义同值行的处理方式。

把排序定义和窗口帧分开设计

如果调用方既要累计金额又要最近三条事件的平均金额，两者只共享基础分区和排序。可以让 w_order 不包含帧，再分别添加范围，避免重复输入排序表达式。

-- 基础窗口只定义分区与排序，两个派生窗口保留各自的统计范围。
SELECT
    account_id, event_id, event_time, amount,
    SUM(amount) OVER w_running AS running_amount,
    AVG(amount) OVER w_recent AS recent_average
FROM ledger_events
WINDOW
    w_order AS (
        PARTITION BY account_id
        ORDER BY event_time, event_id
    ),
    w_running AS (
        w_order ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ),
    w_recent AS (
        w_order ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
    )
ORDER BY account_id, event_time, event_id;

w_recent 取当前行和最多两条前序事件，不是最近三天。即便排序相同，两个帧的计算范围仍然不同。不能把它们合并成一个窗口后继续沿用原来的列名。

对于这里的累计聚合，显式 ROWS 可以让逐行含义清楚可见。省略帧但保留 ORDER BY 时，默认范围会包含当前排序值相同的同值行，可能与期望的逐条累计不同。窗口帧规则见：https://dev.mysql.com/doc/refman/8.4/en/window-functions-frames.html。

遇到继承冲突先修语义

命名窗口不是允许任意覆写属性的模板。基础窗口已经有 ORDER BY 时，不要再在引用处添加另一个 ORDER BY 试图覆盖；已有的分区属性也不能在引用处重写。需要反向排序时，定义另一个合适的窗口，不要依靠名字掩盖不同需求。

出错时先核对窗口名是否处于同一查询块、继承属性是否重复、引用链是否成环。业务 SQL 由程序拼装时，排序字段及方向应从固定可选项中选择；不要把外部字符串直接当 SQL 标识符。参数值与 SQL 结构不是同一种输入。

保留版本与执行计划的边界

MySQL 8.4 的优化说明区分了排序复用与窗口合并：多个窗口排序要求相同时，后续窗口可以跳过排序；重复写相同 OVER 定义则不会自动合并为一个窗口求值步骤，官方给出的表达方式是 WINDOW 命名引用。参考：https://dev.mysql.com/doc/refman/8.4/en/window-function-optimization.html。

因此，不应按 OVER 出现次数直接推断发生多少次排序，也不应承诺改成命名窗口就一定缩短耗时。分区规模、表达式、其他排序要求及实际数据都需要纳入判断。复用名字首先使公共规则集中，成本结论应来自读者所在环境的执行计划和测量。

读者若要观察窗口计划，可对自己的只读查询使用 EXPLAIN FORMAT=JSON，关注 windowing 部分。它不等于真实耗时报告；本文不生成虚构计划，不提供已测性能数字，也不运行数据库来制作图片。最终 ORDER BY 仍可能需要独立处理，不能见到输出顺序相同就删掉它。

用小数据检查结果而不是猜性能

可以在独立测试环境中准备以下临时表。它与前面的查询使用相同字段，不读取生产表，也不需要全局改优化器开关。

-- 只在独立测试会话执行，临时表随会话结束释放。
CREATE TEMPORARY TABLE ledger_events (
    account_id INT NOT NULL,
    event_id INT NOT NULL,
    event_time DATETIME NOT NULL,
    amount DECIMAL(10,2) NOT NULL,
    PRIMARY KEY (account_id, event_id)
);

-- 前两条故意使用相同时间，用于检查排序补充键的含义。
INSERT INTO ledger_events VALUES
(9, 11, '2026-01-01 10:00:00', 12.00),
(9, 12, '2026-01-01 10:00:00', 18.00),
(9, 13, '2026-01-01 11:00:00',  6.00),
(9, 14, '2026-01-01 12:00:00', 24.00);

-- 准备完成后执行上文查询；结束后显式释放本会话测试表。
-- DROP TEMPORARY TABLE ledger_events;

按示例数据手算，event_id 为 14 的行累计金额为 60，最近三条事件的平均金额为 16；两者来自不同范围。这是数学预期，不是数据库运行记录。先确认定义复用前后每列含义相同，再讨论是否减少重复排序。

相同窗口名可以跨两条 SELECT 共享排序吗？

不能。名字只在所属查询块内表达规则，不能让独立查询共享上次执行的排序结果。

只把 ASC 改成 DESC 还能当成相同排序吗？

不能据此作同序假设。方向变了就应重新判断业务结果与排序需求，不为减少排序而倒置累计含义。

最终写一个 ORDER BY 就足够了吗？

不够。窗口内决定计算顺序，查询末尾决定展示顺序。它们职责不同，应分别声明。

简明做法是：完全相同的窗口使用一个名字；同序但不同帧的窗口共享无帧基础定义；统计范围、展示顺序及性能证据分别交代。这样复用的是确切规则，而不是一个含糊的“排序优化”承诺。