Question

我们的数据库中有一个怪物视图，它在大约9亿行的宽视图上进行一些条件聚合。做条件聚合它使用多个案例表达式。我尽可能地优化了索引，并且此视图所基于的视图相对快速地返回数据。然而，一旦它试图立即完成所有这些聚合，性能就会下降。我可以找到here视图的代码，以防您想看到它，但我不确定我的问题是否有必要。

我随机选择了10K个联系人并插入到表中，并在表的ContactID上进行了INNER JOIN，并查看选择所有聚合列的情况。返回结果大约需要30分钟。可以在here找到查询的估计计划。

当我在视图中为每个聚合创建一个选择并逐个运行它时，我会在大约5分钟内得到结果。

SELECT  [TDV].[ContactID],
        [TDV].[Dog_FoodTx12mth]
FROM    [Dimension].[Transactions_DataView] [TDV]
    INNER JOIN [Dimension].[Contacts]
        ON     [Contacts].[ContactID] = [TDV].[ContactID];
GO
SELECT  [TDV].[ContactID],
        [TDV].[Cat_FoodTx12mth]
FROM    [Dimension].[Transactions_DataView] [TDV]
    INNER JOIN [Dimension].[Contacts]
        ON     [Contacts].[ContactID] = [TDV].[ContactID];
--repeat the pattern above for each individual aggregate

这对我来说没有多大意义，因为查询将需要在每次运行时从基础表中提取数据，我本来想过做一次数据然后将它们聚合在一起就是更快。

有没有人知道为什么会这样？

编辑：

感谢您的所有回复。

问题可以归结为为什么使用多个DISTINCT Aggregate对性能有负面影响？

Answer 1

我发现这个MSDN article解释了原因。

引用文章：＆＃34; SQL Server 2008不会“沿途”计算这些不同的聚合。将一个或多个不同的聚合与同一选择列表中的非不同聚合混合，或混合两个或更多不同的聚合，导致假脱机和重读中间结果 - 比在单独的查询中计算不同的聚合更昂贵！在最坏的情况下，例如上面的代码片段，这是不可避免的。 SQL Server 2008查询处理器无法在不破坏流的情况下计算流上的聚合。因此，计算不同的聚合会消耗流，必须为其他聚合重新计算。＆＃34;

希望这将有助于将来的人。

感谢@iamdave指出我正确的研究方向。

多个聚合案例表达性能

1 个答案: