Question

我们有一个包含产品属性的17Mil行的表，假设它们是：

brandID，sizeID，colorID，price，shapeID

我们需要按品牌和尺寸查询聚合。目前，我们通过执行以下操作来查询和过滤此数据：

select brandID, sizeID, count(*) 
from table where colorID in (1,2,3) and price=10 and shapeID=17
--"additional complex where clause here"
group by brandID, sizeID
order by brandID, sizeID

我们会报告这些数据。问题是，运行此查询需要10秒左右（这是一个非常简单的示例），尽管实际返回的数据只有几百行。

我认为我们已经达到了索引此表的能力，所以我认为任何数量的索引都不会让我们接近即时结果。

我对OLAP或其他分析服务知之甚少，但SQL Server可以预先过滤或预先聚合此表，以便可以执行上述查询（或类似的返回等效数据）吗？或者在一个非常大的表上处理任意where子句的最佳方法是什么？

Answer 1

我认为这是olap cube的完美候选者。我有数百万行的事实数据。我正在做你上面描述的那种查询，查询会在几分钟内回复。我将其移动到OLAP多维数据集中，现在查询几乎是即时的。 olap有一点学习曲线。我强烈建议你找一个简单的立方体建筑的教程，以便了解它。多年来DBA的同事一直在告诉我有关立方体的事情，我从来没有完全理解过。现在我不知道为什么没有它就这么久。

除了OLAP之外，您可能还想研究索引视图，但如果您以多种方式对数据进行切片，那可能是不可行的。

Answer 2

没有关于表结构和物理环境以及（非）聚簇索引等的具体信息，我首先要查找瓶颈的是查询的“显示执行计划”，还有数据库引擎优化顾问和SQL分析器。希望这可以帮助。

Answer 3

取决于您的索引和架构

无论如何，此查询的索引应该是

之一

CREATE INDEX IX_foo ON table (shapeID, price, colorID) INCLUDE (brandID, sizeID)
CREATE INDEX IX_foo ON table (shapeID, price, colorID, brandID, sizeID)

但是，你在这里添加了“其他复杂的where子句”，这可以减少一个好的答案

我的想法：

WHERE子句很重要，因为这会减少行数
ORDER BY不如aggregate / WHERE
覆盖查询以删除键查找

额外的事情：

（1,2,3）中的colorID是坏的，因为它是OR
确保参数数据类型与列数据类型完全匹配以避免隐式转换
你可以在一个小位周围交换shapeID，Price和colorID来查看最好的（或创建一些索引，看看它使用哪一个）
您是否有服务器瓶颈（例如在SQL Express上运行等）？

Answer 4

如果您正在使用SQL 2008并且具有一些特定的常用过滤，请考虑使用过滤索引（可能与gbn建议的INCLUDE索引结合使用）。

假设您只有五个sizeID值。您可以将当前索引分解为多个筛选索引（例如，“WHERE sizeID = 1”）。

将过滤与INCLUDE结合使用可以使您的查询更快地返回。

参考：Exploring SQL Server 2008’s Filtered Indexes

SQL Server聚合非常大的表

4 个答案: