分区大表 - 索引

Question

我被分配了一项任务来改进几个表的数据管理过程（数据归档） 表是 200gb

我现在正在阅读有关表分区和最佳实践的信息 据我所知，这个过程就像

• 创建文件组和文件
• 创建分区函数
• 分区方案 -（将间隔映射到适当的文件组）
• 重新创建聚集索引 - 这是将表物理移动到另一个文件的时刻
• 利润 :)

但找不到一个信息 此时现有的非聚集索引发生了什么？ 从这里：http://technet.microsoft.com/en-us/library/ms187526(v=sql.105).aspx 我找到了

虽然分区索引可以独立于它们的基表来实现，但通常设计一个分区表然后在表上创建索引是有意义的。执行此操作时，SQL Server 使用与表相同的分区方案和分区列自动对索引进行分区。因此，索引的分区方式与表的分区方式基本相同。这使得索引与表对齐。

还有一个

对唯一的非聚集索引进行分区时，索引键必须包含分区列。在对非唯一、非聚集索引进行分区时，SQL Server 默认将分区列添加为索引的非键（包含）列，以确保索引与基表对齐。如果分区列已经存在于索引中，SQL Server 不会将其添加到索引中。

但是这些都没有提到我的问题 我是否必须为现有的非聚集索引显式创建分区函数，这些索引在其定义中是否/没有分区列？

假设我们有这样的表

表 A - col1 col2 col3

在 col1 上有聚集索引 并且非聚集在第 3 列 在 PRIMARY 分区上

分区后col3上的非聚集索引会发生什么，它将与表对齐还是仍然驻留在PRIMARY分区上

Answer 1

您应该对齐索引。有两个主要的力量将你拉向这个方向：

• 快速分区切换操作需要对齐索引。在处理大型数据集时，删除过时数据（已超过所需保留期的数据）与添加新数据同样重要。分区切换操作是迄今为止删除旧数据最有效的方法。见How to Implement an Automatic Sliding Window in a Partitioned Table

• 查询处理器喜欢对齐的索引，讨厌未对齐的索引。例如见Memory Limitations and Partitioned Indexes:

对于对齐和非对齐索引，内存需求可以是 如果 SQL Server 将并行度应用于构建，则更大 在多处理器计算机上运行。这是因为更大 并行度越高，内存需求越大。为了 例如，如果 SQL Server 将并行度设置为 4，则未对齐 具有 100 个分区的分区索引需要足够的内存 四个处理器同时对 4,000 页或 16,000 页进行排序。 如果分区索引对齐，则内存需求减少 四个处理器对 40 页或 160 (4 * 40) 页进行排序。

在您的情况下，这意味着将分区列显式添加到每个非聚集索引，并在与基表（聚集索引）相同的分区方案上声明每个非聚集索引。不要尝试为非聚集索引创建不同的分区函数/方案。将分区列添加到每个索引会在您的数据模型中产生深远的影响，例如。您将无法再声明一个 不 包含分区列的主键约束（这会波及所有引用分区表的外键定义！）但这是您的代价 当您接受分区作为解决方案时，已经购买了，请参阅How To Decide if You Should Use Table Partitioning。

Answer 2

一般来说，您通常会删除所有非聚集索引，然后在新方案中重新创建它们。这将以与聚集索引（和行数据）类似的方式将它们拆分到表分区中。

如果您不这样做，它们将留在原始文件组（主文件组或任何位置）