SQL Server 2008分区表和并行性

Question

我的公司正在迁移到SQL Server 2008 R2。我们有一个包含大量存档数据的表。使用该表的大多数查询在where语句中使用DateTime值。例如：

查询1

SELECT COUNT(*) 
FROM TableA 
WHERE 
     CreatedDate > '1/5/2010' 
     and CreatedDate < '6/20/2010'

我假设分区是在CreatedDate上创建的，并且每个分区都分布在多个驱动器上，我们有8个CPU，数据库中有5亿条记录平均分布在2008年1月1日之间的日期中到2011年2月24日（38个分区）。该数据也可以分成一年的四分之一或其他时间长度，但可以将假设保留为几个月。

在这种情况下，我相信将使用8个CPU，并且只查询6个分区的1/5/2010到6/20/2010之间的日期。

现在，如果我运行以下查询并且我的假设与上面的相同，该怎么办。

查询2

SELECT COUNT(*) 
FROM TableA 
WHERE State = 'Colorado'

问题？
1.是否会查询所有分区？是
2.是否将全部8个CPU用于执行查询？是的
。3.与查询未分区的表相比，性能会更好吗？是的
4.我还有什么想念的吗？
5.分区索引有什么帮助？

根据我对SQL Server
2008分区表和并行的有限知识，我回答了上面的前3个问题。但是，如果我的答案不正确，您是否可以提供任何有关我不正确的原因的反馈。

资源：

• 视频：演示SQL Server 2008分区表并行化（5分钟长）
• MSDN：分区表和索引
• MSDN：设计分区来管理数据子集
• MSDN：分区表和索引上的查询处理增强功能
• MSDN：Word Doc：使用SQL Server 2008的分区表和索引策略白皮书

BarDev

Answer 1

分区可以提高性能-我已经看过很多次了。开发分区的原因过去和现在都是性能，尤其是对于插入而言。这是来自现实世界的示例：

据我们所知，我在SAN上有多个表，其中有一个大的ole
honking磁盘。SAN管理员坚持认为，SAN知道这一切都不会优化数据的分发。分区可能有什么帮助？事实：确实如此。

我们使用相同的方案（FileID％200）对多个表进行了分区，其中主分区上有200个分区。如果拥有分区方案的唯一原因是“交换”，那将有什么用？没有，但是分区的目的是性能。您会看到，每个分区都有自己的分页方案。我可以一次将数据写入所有这些数据，并且没有死锁的可能性。由于每个写入过程都有一个等同于分区的唯一ID，因此无法锁定页面。200个分区将性能提高了2000倍（事实），并且死锁从每小时7500个下降到每天3-4个。出于简单的原因，页面锁定升级总是发生在大量数据和大量OLTP系统的情况下，而页面锁定是导致死锁的原因。分区，甚至在相同的卷和文件组上，

选择数据虽然有好处，但没有那么大。但是通常会考虑到DB的目的来开发分区方案。我敢打赌Remus在开发他的方案时会考虑增量加载（例如每日加载），而不是考虑事务处理。现在，如果人们经常选择带有锁定（已提交读）的行，那么，如果进程尝试同时访问同一页，则可能导致死锁。

但是Remus是正确的-在您的示例中，我看不出任何好处，实际上，查找跨不同分区的行可能会产生一些开销。