已分区表和已分区索引概念

在维护数据集合的完整性时,使用分区可以快速而有效地管理和访问数据子集,从而使大型表或索引更易于管理。通过使用分区,将数据从 OLTP 加载到 OLAP 系统之类的操作仅需几秒钟即可完成,不像在 SQL Server 的早期版本那样需要几分钟或几小时。对数据子集执行的维护操作只针对所需的数据而不是整个表,因此,这些操作的执行效果也会更为有效。

注意注意

只有 SQL Server Enterprise Edition、Developer Edition 和 Evaluation Edition 支持已分区表和已分区索引。

已分区表和已分区索引的数据划分为分布于一个数据库中多个文件组的单元。数据是按水平方式分区的,因此多组行映射到单个的分区。对数据进行查询或更新时,表或索引将被视为单个逻辑实体。单个索引或表的所有分区都必须位于同一个数据库中。

已分区表和已分区索引支持与设计和查询标准表和索引相关的所有属性和功能,包括约束、默认值、标识和时间戳值以及触发器。因此,如果要实现位于服务器本地的已分区视图,则可能需要改为实现已分区表。

决定是否实现分区主要取决于表当前的大小或将来的大小、如何使用表以及对表执行用户查询和维护操作的完善程度。

通常,如果某个大型表同时满足下列两个条件,则可能适于进行分区:

  • 该表包含(或将包含)以多种不同方式使用的大量数据。

  • 不能按预期对表执行查询或更新,或维护开销超过了预定义的维护期。

例如,如果对当前月份的数据主要执行 INSERT、UPDATE、DELETE 和 MERGE 操作,而对以前月份的数据主要执行 SELECT 查询,则按月份对表进行分区可能会使表的管理工作更容易一些。如果对表的常规维护操作只针对一个数据子集,那么此优点尤为明显。如果该表没有分区,那么就需要对整个数据集执行这些操作,这样就会消耗大量资源。例如,通过分区,可以针对具有只写数据的单个月份执行类似索引重新生成和碎片整理的维护操作,而只读数据仍可用于联机访问。

扩展一下此示例,假设要将该表中一个月的只读数据移至数据仓库表中以进行分析。分区后,可以快速将数据子集分散到临时区域中以进行脱机维护,然后将这些数据作为分区添加到现有的已分区表(假定这些表都位于同一个数据库实例中)中。类似这样的操作通常只需几秒钟,而不是像未分区时那样需要数分钟或数小时。

如果根据频繁执行的查询的类型和硬件配置正确地设计分区,那么对表或索引进行分区可以提高查询性能。有关详细信息,请参阅设计分区以提高查询性能

分区通常与 SQL Server 复制连用。使用分区可使您通过有效减少复制系统不得不管理的数据和元数据量,优化事务复制的性能和合并复制。复制支持每个表最多 1024 个分区。有关详细信息,请参阅复制已分区表和索引

为了提供分区解决方案如何应用于真实数据库的示例,AdventureWorks2008R2 示例数据库中提供了可以实现的分区方案。在 在 AdventureWorks2008R2 示例数据库中分区中解释了该方案。

分区结构

在 SQL Server 中,数据库中的所有表和索引都视为已分区表和索引,即使这些表和索引只包含一个分区。实际上,分区构成了表和索引的物理结构中的基本组织单位。这意味着表和索引的逻辑和物理结构是由单个分区表和索引的多个分区镜像组成。有关详细信息,请参阅表组织和索引组织

请参阅

概念