MySQL named window 怎样复用多个查询的窗口定义

MySQL 的 named window 解决的是同一个查询块内多个窗口函数重复书写窗口定义的问题。如果“多个查询”指几条独立 SELECT，不能先定义一次 WINDOW，再让后续语句直接使用这个名字；应在各条 SQL 中保留定义，或在应用层共享受控的 SQL 模板。窗口名不是可跨连接使用的持久化对象。

MySQL 官方文档：https://dev.mysql.com/doc/refman/8.4/en/window-functions-named-windows.html

先区分多个函数和多条独立查询

报表接口需要统一口径时，首先确定复用的对象是什么：是同一行上几个指标的分区、排序，还是几份报表的完整SQL。把两者混在一起，容易把局部窗口名当作数据库全局配置。

下面采用MySQL 8.4语法。示例数据、窗口名和字段为原创教学材料，未在本文运行，也不需要为理解配图启动数据库。

把共有分区和排序写成一个名字

设报表按团队展示每日处理量。team_id 是分区键，work_day 与唯一 sample_id 组成稳定排序。把共有规则命名为 w_order，序号函数直接使用它；累计求和则在引用时补充明确的 ROWS 帧。

-- CTE提供小样本，不创建或改写业务表。
WITH report_samples AS (
    SELECT 1 AS sample_id, 10 AS team_id,
           CAST('2026-01-01' AS DATE) AS work_day, 4 AS units
    UNION ALL SELECT 2, 10, CAST('2026-01-02' AS DATE), 7
    UNION ALL SELECT 3, 10, CAST('2026-01-02' AS DATE), 2
    UNION ALL SELECT 4, 20, CAST('2026-01-01' AS DATE), 5
)
SELECT
    sample_id, team_id, work_day, units,
    ROW_NUMBER() OVER w_order AS seq_no,
    -- 逐行累计：明确按行位置计算，不依赖默认RANGE帧。
    SUM(units) OVER (
        w_order ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS running_units
FROM report_samples
WINDOW w_order AS (
    PARTITION BY team_id
    ORDER BY work_day, sample_id
)
-- 窗口排序不代替最终输出排序。
ORDER BY team_id, work_day, sample_id;

按该样本推导，team_id=10的累计值依次应为4、11、13，序号为1、2、3；team_id=20从自己的分区重新开始，累计为5。这是预期结果说明，不是数据库运行日志。

WINDOW 子句的位置在 HAVING 之后、最终 ORDER BY 之前；没有 HAVING 时也不需要添加空的 HAVING。OVER w_order 表示直接引用，OVER (w_order ...) 用于在允许的范围内补充窗口属性。

这段查询里的关系可以概括为：report_samples 提供行，w_order 定义分区与排序，ROW_NUMBER 共享顺序，SUM 另带累计帧。命名复用的是规则，不是把多个指标合成一个计算结果。

扩展窗口只补缺项，不覆盖原定义

接口里常见两种指标：截至当前行的累计值，以及整个团队的总量。它们可以共享分区和排序，但帧范围不同。基础窗口不提前写帧，便于派生出两个语义明确的窗口。

-- 本例同样是独立语句：重新定义数据与窗口，不依赖上一条SQL。
WITH report_samples AS (
    SELECT 1 AS sample_id, 10 AS team_id,
           CAST('2026-01-01' AS DATE) AS work_day, 4 AS units
    UNION ALL SELECT 2, 10, CAST('2026-01-02' AS DATE), 7
    UNION ALL SELECT 3, 10, CAST('2026-01-02' AS DATE), 2
)
SELECT sample_id, units,
       SUM(units) OVER w_running AS running_units,
       SUM(units) OVER w_all AS team_units
FROM report_samples
WINDOW
    w_base AS (
        PARTITION BY team_id ORDER BY work_day, sample_id
    ),
    -- 两个窗口只补各自的帧，不改写基础分区或排序。
    w_running AS (
        w_base ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ),
    w_all AS (
        w_base ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
    )
ORDER BY sample_id;

同样按样本推导，running_units是4、11、13，team_units三行都应为13。若基础窗口已有ORDER BY，不能在引用中再写另一套ORDER BY去覆盖它；已有PARTITION BY也不能重复指定。需要相反排序时，可选择只共享分区，或另定义一个独立窗口。

窗口之间也不能形成循环引用。工程上不必为了减少几个字符建立多层继承：一层基础规则配少量有业务语义的派生窗口，通常更容易让报表维护者看清口径。

多条报表 SQL 怎样共享口径

若不同API分别返回团队趋势和团队合计，建议先把业务口径拆成“分区字段、稳定排序字段、帧含义”三项，再在受控模板中组合完整SQL。每个查询块仍声明自己的WINDOW，不依赖上一条语句或某个连接保存过窗口名。

模板复用时，日期、团队ID等数据值使用驱动参数绑定；窗口名、列名和排序方向不能随意当数据参数传入，应来自程序内固定的允许集合。这样做既便于统一口径，也避免把任意输入拼进SQL结构。

如果需要外层按累计结果过滤，可以由内层CTE或派生表输出 running_units，再在外层过滤这个结果列。外层读取的是内层输出，并不是继承了w_order或w_running这个名字。若外层还要计算新的窗口函数，应声明外层所需的定义。

是否改成视图或其他数据库对象，要看真正需要共享的是结果口径还是查询模板，并评估过滤应在窗口计算之前还是之后发生。不能只把SQL包进视图，就宣称所有报表的统计范围都保持不变。

结果偏差先查这几个边界

为什么同一天几行的累计结果一起增加？

有ORDER BY但没写帧时，默认帧是截至当前排序值同伴行的RANGE范围，不一定逐物理行累计。若需要逐行累计，明确写ROWS，并用能打破并列的字段建立稳定排序；若业务需要同日合并口径，则保留相应语义，不应机械改成逐行。

WINDOW 会改变 WHERE 的过滤范围吗？

它不替代WHERE。窗口函数处理查询块在相应阶段保留下来的行；将过滤放在内层和外层可能改变累计范围。比如“仅显示某日之后的结果”与“只用某日之后的数据重新累计”是两个不同接口约定，应先确定业务需要哪一个。

相同窗口名是不是保证只排序一次？

命名首先改善SQL表达与维护，不能仅凭写法推断实际排序次数、内存占用或速度。需要性能结论时，由读者对实际数据和环境查看计划、进行受控测量；本文没有执行EXPLAIN或基准，也不承诺性能倍数。

最终取舍很明确：同一查询块内把重复规则命名；不同帧分别表达；跨独立查询则共享受控SQL或结果定义，而不是试图共享一个局部窗口名。

参考：MySQL 8.4 命名窗口；窗口帧范围；窗口函数语义。