下面的代码中求和函数如何与 OVER() 子句中的 ORDER BY 一起计算每个窗口的小计？

Question

我们需要编写以下查询： 编写一个查询，返回

sales_date

、

brand

、

quantity

以及别名为

running_total_quantity

的每月销售额运行总计。

表：

销售日期	品牌	数量
2022-01-31	苹果	50
2022-02-28	苹果	40
2022-03-31	苹果	25
2022-04-30	苹果	30
2022-05-31	苹果	47
2022-06-30	苹果	40

正确的代码是：

SELECT sales_date, brand, quantity, SUM(quantity) OVER(ORDER BY sales_date) AS running_total_quantity
FROM apple_sales_quantity_by_month

输出：

| sales_date |  brand   | quantity | running_total_quantity | 
| ---------- | -------- | -------- | ---------------------- |
| 2022-01-31 |  Apple   |   50     |          50            |
| 2022-02-28 |  Apple   |   40     |          90            |
| 2022-03-31 |  Apple   |   25     |          115           |
| 2022-04-30 |  Apple   |   30     |          145           |
| 2022-05-31 |  Apple   |   47     |          192           |
| 2022-06-30 |  Apple   |   40     |          232           |

但我不明白在

ORDER BY

子句中使用运算符

OVER()

如何导致计算 INTERMEDIATE 总数。我认为

ORDER BY

只是按日期对数据进行排序，然后 sum 函数将排序后的数据加在一起。 如果有人能准确地向我解释如何逐步计算此问题中的小计，我将不胜感激。 或者它只是

ORDER BY

运算符的特殊功能，可以对使用窗口函数时出现的小计进行求和？一般来说，我将不胜感激任何解释！

我尝试在没有

ORDER BY

的情况下使用其他窗口函数编写代码，但这里最佳解决方案是使用

ORDER BY

，我想确切地了解它在这里是如何工作的。

Answer 1

我试着理解你到底是什么意思。来自 PostgreSQL 文档：

“当聚合函数用作窗口函数时，它会聚合当前行的窗口框架内的行。与

ORDER BY

和默认窗口框架定义一起使用的聚合会产生“运行总和”类型的行为，这可能会导致或者可能不是想要的。要获得整个分区的聚合，请省略

ORDER BY

或使用

ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING

。可以使用其他帧规范来获得其他效果。”