分区大表 - 索引
Posted
技术标签:
【中文标题】分区大表 - 索引【英文标题】:partitioning big tables - indexes 【发布时间】:2012-08-07 07:58:17 【问题描述】:我被分配了一项任务来改进几个表的数据管理过程(数据归档) 表是 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分区上
【问题讨论】:
【参考方案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。
【讨论】:
【参考方案2】:一般来说,您通常会删除所有非聚集索引,然后在新方案中重新创建它们。这将以与聚集索引(和行数据)类似的方式将它们拆分到表分区中。
如果您不这样做,它们将留在原始文件组(主文件组或任何位置)
【讨论】:
以上是关于分区大表 - 索引的主要内容,如果未能解决你的问题,请参考以下文章