SQL Server 2008中分区表和并行

我公司正朝着到SQL Server 2008 R2。我们有一个包含大量存档数据的表格。大多数使用此表的查询在where语句中使用DateTime值。例如：SQL Server 2008中分区表和并行

查询1

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

我做的是分区上创建CreatedDate和每个分区跨多个驱动器摊开的假设，我们有8个CPU，并且还有500万条记录中数据库在2008年1月1日至2011年2月24日期间均匀分布（38个分区）。这些数据也可以分成一年的四分之一或其他时间段，但让我们将假设保持数月。

在这种情况下，我会认为，8 CPU的会被利用，只有6个分区将被用于查询2010年1月5日和2010年6月20日之间的日期。

如果现在我跑下面的查询和我的假设与上面相同。

查询2

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

问题？
1.是否会查询所有分区？是
2.是否将使用所有8个CPU来执行查询？是
3.将性能比查询未partitoned表更好吗？是
4.有什么我失踪？
5.分区索引如何提供帮助？

我回答了上面的第3个问题，根据我对SQL Server 2008分区表的了解有限知识&并行性。但是，如果我的答案不正确，你能否提供任何我错误的反馈。

资源：

视频：Demo SQL Server 2008 Partitioned Table Parallelism（5分钟长）
MSDN：Partitioned Tables and Indexes
MSDN：Designing Partitions to Manage Subsets of Data
MSDN：Query Processing Enhancements on Partitioned Tables and Indexes
MSDN：Word文档：Partitioned Table and Index Strategies Using SQL Server 2008白纸

BarDev

来源

2011-02-24 Mike Barlow - BarDev

似乎像DBA这样的问题会更适合在Serverfault（或者我们现在有一个DBA站点？）......但我不确定。 – derobert 2011-02-24 19:32:29

我会出去Serverfault并找出答案。 – 2011-02-24 22:05:10

根据回复，我们的表格确实具有Clusterd Index和其他列上的其他索引，例如State。我努力让帖子尽可能小，而不用考虑服务器，数据库和表格配置的每个细节。也许我应该也已经确定了这些假设。假设服务器，数据库和对象对象遵循Microsoft的最佳实践。 – 2011-02-24 22:17:48

分区可以提高性能 - 我已经看过很多次了。分区开发的原因是性能，特别是对于插入。这里是一个来自真实世界的例子：据我们所知，我在SAN上有多个表，有一个大笔记本硬盘。 SAN管理员坚称，SAN知道所有这些都不会优化数据分布。分区如何可能有所帮助？事实：它确实如此。

我们使用相同的方案（FileID％200）对主表上的200个分区ALL进行分区。如果拥有分区方案的唯一原因是“交换”，那会有什么用？没有，但分区的目的是性能。你看，每个分区都有自己的分页方案。我可以一次将数据写入所有数据，不存在死锁的可能性。页面不能被锁定，因为每个写入过程都有一个唯一的ID，相当于一个分区。 200个分区提高了2000倍（事实）的性能，并且死锁从每小时7500个降至每天3-4个。这很简单，因为页锁升级总是在大量数据和大容量OLTP系统中发生，并且页锁导致死锁。即使在相同的卷和文件组中，即使在相同的卷和文件组中，分区也会将分区数据放置在不同的页面上，并且锁定升级没有效果，因为进程不会尝试访问相同的页面。

对于选择数据，其好处是存在的，但并不是很好。但通常情况下，分区方案将在考虑DB的前提下开发。我敢打赌，Remus开发他的计划时采用了增量加载（比如日常加载），而不是考虑事务处理。现在，如果有人经常选择锁定行（读取已提交），那么如果进程尝试同时访问同一页，则可能导致死锁。

但Remus是正确的 - 在你的例子中我看不到任何好处，事实上，在跨不同分区查找行时可能会有一些间接成本。

来源

2011-09-07 20:35:24 user933581

分区是从未提高性能的选项。您可以期望的最好方式是与非分区表进行性能对比。通常你会得到一个随着分区数量增加的回归。为了性能，你需要索引，而不是分区。分区用于数据管理操作：ETL，档案等。有些人声称，分区消除可能会提高性能，但对于任何分区消除都可以将主键索引放在同一列上，因为分区列会给出更好的结果。

将所有分区进行查询？

该查询需要State上的索引。否则是表扫描，并将扫描整个表。对分区表的表扫描是总是比扫描相同大小的非分区表慢。索引本身可以在同一分区方案上对齐，但主键必须是State。

是否所有8个CPU都用于执行查询？

并行性与分区无关，尽管存在相反的普遍误解。分区和非分区范围扫描都可以使用并行运算符，这将是查询优化程序的决定。

性能是否会比查询不是分区的表更好？

没有

如何将分区索引帮助吗？

索引将有所帮助。如果索引必须对齐，则必须对其进行分区。非分区索引将比分区索引更快，但无法规避切入/切出操作的索引对齐要求。

如果您正在寻找分区，应该是因为您需要执行快速切入关闭操作，以删除过去保留策略期间或之前类似的旧数据。对于性能，您需要查看索引，而不是分区。

来源

2011-02-24 19:15:10

分区可以帮助性能，因为您可以在不同的磁盘上找到分区。这允许I/O带宽增加=更好的性能。除此之外，还有很多“意见”，除非事实支持，否则我不同意。 http://msdn.microsoft.com/en-us/library/ms177411.aspx – RichardTheKiwi 2011-02-24 19:49:38

非分区表可以位于包含多个文件的文件组上（分布在LUN /磁盘上），这将利用增加的IO带宽*更好*比分区。 – 2011-02-24 19:59:59

我完全同意理查德。我们的数据库在SAN上，并且有多个LUN可用。 Remus，你看过原始文章中的视频吗？这一切都是关于表分区的更好性能。 – 2011-02-24 21:58:39

我的第一个问题是如果你的表有一个聚集索引就可以了。如果没有，你会想要一个。

此外，您需要为您的查询覆盖索引。 Covering Indexes

如果您有大量的历史数据，您可以查看归档过程以帮助加速您的oltp应用程序。

来源

2011-02-24 19:23:05 DForck42

SQL Server 2008中分区表和并行

回答

相关问题