SQL如何计算每个季度的累计利润_窗口函数时间分区

窗口函数计算季度累计利润时必须显式指定ORDER BY时间字段并配合PARTITION BY年份，先聚合再开窗，且需确保时间字段可排序、无歧义。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

窗口函数必须按时间顺序排序，否则累计值会错乱

这里有个常见的误区：以为用 SUM() OVER() 计算季度累计利润时，数据库会自动按时间顺序处理。事实并非如此。即便你的原始数据看起来是按日期排好的，窗口函数内部依然可能打乱顺序，导致累加路径完全错乱——想象一下，把第四季度的利润加到了第一季度前面，这样的累计结果显然毫无意义。

关键在于，必须在 ORDER BY 子句中明确指定时间字段，比如 order_date 或 quarter_start。而且，这个字段必须能唯一、稳定地反映季度的先后顺序：

SELECT
  quarter,
  profit,
  SUM(profit) OVER (ORDER BY quarter ROWS UNBOUNDED PRECEDING) AS cum_profit
FROM quarterly_profit;

需要注意的是，quarter 字段的存储格式至关重要。无论是字符串（如 '2023-Q1'）还是可排序的日期型（如 DATE '2023-01-01'）都可以。如果存储为 INT 类型的 202301，也能正常排序。但若只存成无序的编号（如 1, 2, 3, 4）且没有关联年份信息，那么跨年度的数据就会混在一起，导致累计范围失控。

季度分组不能只靠 GROUP BY，得用 PARTITION BY 控制累计范围

接下来是另一个核心点：如果想实现“每个年度内单独累计”，而不是从历史第一笔数据一直累加下去，那么 PARTITION BY 子句就绝对不能省略。一个典型的错误是只写了 ORDER BY quarter，结果导致2022年第四季度的利润，被错误地累加进了2023年第一季度的累计值里。

正确的做法是，从原始日期字段中提取出年份，并用它来分区。具体函数依数据库而定，推荐使用 EXTRACT(YEAR FROM ...) 或 YEAR(...)：

SELECT
  EXTRACT(YEAR FROM order_date) AS year,
  CONCAT(EXTRACT(YEAR FROM order_date), '-Q', EXTRACT(QUARTER FROM order_date)) AS quarter,
  profit,
  SUM(profit) OVER (
    PARTITION BY EXTRACT(YEAR FROM order_date)
    ORDER BY EXTRACT(QUARTER FROM order_date)
    ROWS UNBOUNDED PRECEDING
  ) AS cum_profit_per_year
FROM sales;

• PARTITION BY 决定了“重置点”：每到新的一年，累计值便会归零重新计算。
• ORDER BY 决定了“累加方向”：这里必须是季度编号（从1到4），而不能是随机的别名。
• 如果直接使用拼接好的字符串 quarter（如 '2023-Q1'），那么直接 ORDER BY quarter 也可以，但务必确保格式统一、无多余空格。为了排序更安全，采用零填充的格式（如 '2023-Q01'）会比 '2023-Q1' 更好。

ROWS UNBOUNDED PRECEDING 是默认行为，但显式写出更可靠

关于窗口框架，这里有个细节值得注意。部分数据库，比如 PostgreSQL，在未显式指定 ROWS 或 RANGE 时，会默认使用 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW。然而，MySQL 8.0+ 和 SQL Server 等数据库则要求明确声明，否则会直接报错，提示类似 Window frame 'rows between unbounded preceding and current row' is required for this function 的信息。

因此，为了代码的清晰度和跨数据库的兼容性，建议始终显式写出 ROWS UNBOUNDED PRECEDING，尤其是在考虑未来可能迁移或维护时：

• ✅ 推荐写法：SUM(profit) OVER (PARTITION BY year ORDER BY qtr ROWS UNBOUNDED PRECEDING)
• ❌ 有风险的写法：SUM(profit) OVER (PARTITION BY year ORDER BY qtr) —— 在某些引擎下可能不报错，但逻辑隐晦，容易被误解为 RANGE 的默认行为。
• ⚠️ 额外提醒：当 ORDER BY 字段的值是离散且无重复时（如规范的季度编号），使用 RANGE UNBOUNDED PRECEDING 的效果与 ROWS 相同。但是，一旦排序字段存在重复值（例如，同一季度的多笔利润在聚合前就直接开窗），RANGE 会把所有具有相同值的行都纳入当前行的窗口进行计算，从而导致利润被重复累加，造成数据失真。

先聚合再开窗，避免同一季度多行导致累计失真

最后，也是至关重要的一步：处理数据的粒度。原始销售表通常按订单明细存储，同一个季度内可能包含成百上千条记录。如果直接在这些明细行上应用窗口函数，SUM() OVER() 会逐行累加，导致所谓的“Q1累计利润”会随着行数变化而出现多个不同的值（第一单的利润、前两单的利润之和……直到最后一单），这显然不是我们想要的“Q1总利润 → Q1+Q2总利润”这样的季度级累计。

所以，必须先按季度进行聚合，再对聚合后的结果应用窗口函数：

WITH quarterly AS (
  SELECT
    EXTRACT(YEAR FROM order_date) AS year,
    EXTRACT(QUARTER FROM order_date) AS qtr,
    SUM(profit) AS quarter_profit
  FROM sales
  GROUP BY 1, 2
)
SELECT
  year,
  qtr,
  quarter_profit,
  SUM(quarter_profit) OVER (
    PARTITION BY year
    ORDER BY qtr
    ROWS UNBOUNDED PRECEDING
  ) AS cum_profit
FROM quarterly;

这个“先聚合，后开窗”的两步结构不能跳过。虽然有些技巧试图在子查询中用 SUM(SUM()) OVER() 的嵌套写法，语法上或许可行，但会严重损害代码的可读性，并且容易在 GROUP BY 逻辑和窗口逻辑之间产生混淆。

真正棘手的情况，其实来自于底层数据的不规范。例如，时间字段缺失（只有月份没有年份），或者季度文本格式混乱（混杂着 'Q1 2023' 和 '2023 Q1' 等多种格式）。必须明确指出，窗口函数本身无法拯救格式混乱的时间维度。这类数据质量问题，必须在进行任何分析计算之前，通过数据清洗步骤予以解决。