SQL Server 2008-分区和聚集索引

因此，请允许我说我对数据库的设计没有完全控制权，因此，对于本场景而言，无法更改当前系统的许多方面。

关于我们应该如何重新考虑设计方面的评论可能是正确的，但无济于事:)

我有一个很大的表，大约150个字段宽，大约600m行，它驱动着大量的进程。这是在数据仓库的情况下，因此我们在计划的加载过程之外没有任何更新/插入，因此它的索引很高。

已做出尝试对该表进行分区的决定，并且我对索引已分区表有些担忧。我没有分区方面的经验，因此不胜感激任何输入或链接。我在BOL或msdn上找不到具体的位置。

目前我们群集上一个领域，我们称之为IncidentKey这是一个varchar(50)，而不是唯一的-我们可以1-100记录与同一之间有IK（没有意见，请）。我们经常会在旧IncidentKey记录上获取新数据，因此也不是连续的。

我了解我需要IncidentDate在群集索引键中包含分区字段，以使分区正常工作。我在想IncidentKey, IncidentDate。

问题是，如果“新”分区中的记录应该在聚簇索引中“旧”分区中的记录之前，则聚簇索引的机制将如何在分区表的2部分键上工作？

例如，我有5条记录：

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

如果我得到一条新记录，ABC123, 2/1/2011它将需要在聚集索引BEFORE中 XYZ999, 1/1/2010。这是如何运作的？

我假设使用碎片和指针，但是找不到具有双部分键的分区表上非分区聚簇索引的物理存储和配置的任何信息。

分区表实际上更像是缝合在一起的单个表的集合。因此，在通过IncidentKey和进行集群划分的示例中IncidentDate，您说分区函数将表分为两个分区，以便1/1/2010位于分区1中，而7/1/2010是分区2。数据将按以下方式放在磁盘上：

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

在低层次上，确实有两个不同的行集。是查询处理器，它通过创建计划来一起查找，扫描和更新所有行集，从而给出单个表的错觉。

任何非聚集索引中的任何行都将具有与其对应的聚集索引键，例如ABC123,7/1/2010。由于聚集索引键始终包含分区键列，因此引擎将始终知道在聚集索引的哪个分区（行集）中搜索该值（在本例中为分区2）。

现在，无论何时要处理分区，都必须考虑NC索引是对齐的（NC索引的分区与聚簇索引完全相同）还是不对齐的（NC索引未分区，或者与聚簇索引的分区不同） 。非对齐索引更灵活，但存在一些缺点：

• 非对齐索引对于某些查询计划需要大量内存
• 不对齐索引会阻止有效的分区切换操作

使用对齐的索引可以解决这些问题，但会带来一系列问题，因为此物理存储设计选项会波动到数据模型中：

• 索引对齐意味着无法再创建/强制使用唯一约束（分区列除外）
• 引用分区表的所有外键必须在关系中包括分区键（因为分区键由于对齐而在每个索引中），因此这又要求引用分区表的所有表都包含分区键列值。考虑Orders-> OrderDetails，如果Orders具有OrderID但被OrderDate分区，则OrderDetails必须不仅包含OrderID，而且还包含OrderDate，以便正确声明外键约束。

我发现在部署分区的项目开始时很少注意到这些效果，但是它们存在并且会带来严重的后果。

如果您认为对齐索引是一种罕见或极端的情况，请考虑一下：在许多情况下，ETL和分区解决方案的基石是临时表的快速切换。切入操作需要对齐的索引。

哦，还有一件事：我关于外键的所有论点以及将分区列值添加到其他表的连锁反应同样适用于joins。

当聚集索引具有多个分区时，每个分区都有一个B树结构，其中包含该特定分区的数据。例如，如果聚簇索引具有四个分区，则有四个B树结构；每个分区一个。参考 聚集索引结构

分区索引的特殊准则

您可以重建分区索引的特定分区。

例如

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO