Sql 分区方式与分组方式不同

我在正在检查的应用程序中发现了一些SQL查询，如下所示：

SELECT DISTINCT
Company, Warehouse, Item,
SUM(quantity) OVER (PARTITION BY Company, Warehouse, Item) AS stock

我很确定这会产生与以下相同的结果：

SELECT
Company, Warehouse, Item,
SUM(quantity) AS stock
GROUP BY Company, Warehouse, Item

与后一种方法相比，使用第一种方法是否有任何好处（性能、可读性、编写查询时的额外灵活性、可维护性等？

无需使用

sum（）

作为分析函数，并使用

进行分区。我认为他们之间在任何意义上都没有太大的区别。在oracle中，分析函数比聚合函数多得多。我认为sql女士也是如此。例如，
lag（）
，
lead（）
，
rank（）
，
densite rank（）
，等等，仅使用
分组方式就很难实现。
当然，这个论点并不是为了捍卫第一个版本

可能以前在结果集中有更多的计算字段，这些字段不能通过GROUPBY实现
 虽然在查看列时，两个查询的计算结果似乎相同，但实际上它们生成的行集完全不同

第一个使用分析函数的函数将为每个输入行恰好输出一行。也就是说，对于每个库存信息，它将返回一行，其中包含关联公司/仓库/物料的总数量。（顺便说一下，计算平均值对我来说更有意义，但谁知道呢…）

第二个将只为每个公司/仓库/物料组合返回一行

是的，在那个例子中，第一个查询似乎有点无用。。。除非你想计算一些库存水平统计数据，比如按公司/仓库/物品计算的当前库存占总数量的比率（只是一个例子，不知道它是否有任何商业意义！）

分析函数是SQL中非常强大的机制，从某种意义上说，它比GROUPBY更强大。但是小心使用它。。。一个简单的经验法则是：如果你可以使用group by计算，那么，不要使用分析函数；）
 性能：
获胜者：
分组依据

对包含未索引列的大型表进行的一些非常基本的测试表明，至少在我的例子中，这两个查询生成了完全不同的查询计划。按
划分的
显著较慢

groupby
查询计划仅包括表扫描和聚合操作，而
partitionby
计划有两个嵌套的循环自联接。第二次运行时，按
划分的
耗时约2800ms，按
分组的
耗时仅500ms

可读性/可维护性：
获胜者：
分组依据

根据这里的评论者的意见，
按
分区对于大多数开发人员来说可读性较差，因此将来可能也更难维护

灵活性
获胜者：
分区依据

partitionby
为您选择分组列提供了更大的灵活性。使用
groupby
时，所有聚合列只能有一组分组列。使用
DISTINCT+partitionby
可以在每个分区中有不同的列。此外，在某些DBMS上，您可以从
OVER
子句中的更多聚合/分析函数中进行选择。
由于我不得不在一段时间内解析第一个查询，因此它在“可理解性”方面的得分不高…在这种情况下，
分区被
看起来只是误用了，我认为这可能有助于澄清问题difference@SecretSquirrel我看到过这个问题，但它没有给我提供我想要的信息。我想知道使用第一个查询是否有一些不明显的（至少对我来说）好处。第二种观点对我来说也更“自然”。我的基本意思是，从我读到的和理解的内容来看，使用
groupby
和
partitionby
并不是真正可以互换的。他们都做不同的事情。即使查询结果相同，我也不会简单地交换查询。在第一个查询中，在
SELECT
之后有一个
DISTINCT
，因此它只为每个公司/仓库/项目返回一行，就像第二个查询一样。好吧，很公平。。。但是，DISTINCT应用于每个库存行，并且需要考虑每个值：公司/仓库/项目和总和（数量）。如果查看exec计划（好的，它可能取决于您的数据库），分析查询会增加不同的成本，这已经是简单group by的两倍。