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亿条记录均匀分布在1 /的日期1/2008至2011年2月24日（38个分区）。这些数据也可以分为一年或其他持续时间，但是让假设保持数月。

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

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

查询2

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

问题？
    1.是否会查询所有分区？是的
    2.是否所有8个CPU都用于执行查询？是的
    3.性能是否优于查询未分区的表格？是的
    还有什么我想念的吗？     5.分区索引如何帮助？

我回答上面的前三个问题，基于我对SQL Server 2008 Partitioned Table＆amp; amp;并行。但如果我的答案不正确，你能不能提出任何我不正确的反馈意见。

资源：

视频：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 Doc：Partitioned Table and Index Strategies Using SQL Server 2008白皮书

BarDev

Answer 1

分区永远是提高性能的选项。您可以期待的最好的是与非分区表具有相同的性能。通常，您会得到随着分区数量增加的回归。对于性能，您需要索引，而不是分区。分区用于数据管理操作：ETL，归档等。有些人声称分区消除可能会带来性能提升，但对于任何分区消除都可以将前导索引键放在同一列上，因为分区列会产生更好的结果。

是否会查询所有分区？

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

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

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

性能是否优于查询不是的表分配

没有

分区索引如何帮助？

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

如果您正在考虑分区，那应该是因为您需要执行快速接入切换操作以删除保留策略期间之后的旧数据或类似内容。为了提高性能，您需要查看索引，而不是分区。

Answer 2

我遇到的第一个问题是你的表上是否有聚集索引。如果没有，你会想要一个。

此外，您还需要覆盖索引以进行查询。 Covering Indexes

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

Answer 3

分区可以提高性能 - 我已经多次看到它了。开发分区的原因是并且是性能，特别是对于插入。这是来自现实世界的一个例子：

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

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

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

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

SQL Server 2008分区表和并行

3 个答案: