基于模函数的SQL Server表分区?

您只需要将模数列创建为持久化计算列。

Blue Peter Style,这是我之前做的(尽管我不能100%确定分区值子句是否正确):

CREATE PARTITION FUNCTION [PF_PartitonFour] (int)
AS RANGE RIGHT
FOR VALUES (
  0,
  1,
  2)
GO

CREATE PARTITION SCHEME [PS_PartitionFourScheme]
AS PARTITION [PF_PartitonFour]
TO ([TestPartitionGroup1],
    [TestPartitionGroup2],
    [TestPartitionGroup3],
    [TestPartitionGroup4])
GO

CREATE TABLE [my_data] (
  [id] [int] IDENTITY(1,1) NOT NULL,
  [topic_id] [int] NULL,
  [data_value] [decimal](19, 5) NULL
  [PartitionElement] AS [topic_id] % 4 PERSISTED,
) ON [PS_PartitionFourScheme] (PartitionElement);
GO

哈希分区在SQL Server 2005/2008中不可用。必须使用范围分区。

也就是说,您应该知道分区主要是一个存储选项,请参见 Partitioned Table and Index Concepts 以下内容:

分区生成大表或 索引更多 可管理的 ,因为 分区使您能够 管理 和 快速访问数据子集 高效,同时保持 数据收集的完整性。通过 使用分区,这样的操作 作为 加载数据 从OLTP到AN OLAP系统只需几秒钟, 而不是分钟和小时 操作采用的早期版本 SQLServer。 维护 操作 在数据子集上执行的 更有效地执行 因为这些行动只针对 所需的数据,而不是 整张桌子。

如您所见,在msdn中引入分区的重点是维护、可管理性和数据加载。根据我的经验,分区最多可以获得0个性能增益。尤其是在SQL 2005中。通常会导致性能下降。为了提高性能,应该使用正确的聚集索引和正确设计的非聚集索引。

在SQL 2008中,如果从IO的角度正确地分布了并行操作符,那么它们在分区方面有了改进,请参见 Designing Partitions to Improve Query Performance . 但是,它们的好处是微乎其微的,并且被一组适当设计的聚集索引和非聚集索引的好处所掩盖。举例来说,(id,topic_id)中的聚集索引,其中id是一个标识,仅用于按id查找单个项目。另一方面,(topic_id,id)的聚集索引将有益于查找特定主题的任何查询。我不知道您的系统需求和您运行的查询,但是在这么窄的表上有1000万行的性能问题,有点像索引和查询问题,没有分区问题。

从文档中,您似乎必须为函数赋予值:

要创建4个分区…

CREATE PARTITION FUNCTION myRangePF1 (int)
AS RANGE LEFT FOR VALUES (1, 100, 1000);

难道你就不能在这个调用上进行计算,找到合适的值来进行拆分吗?是否将值替换为调用?或者我不明白你为什么要用模量?根据您的ID可能有缺口,您可能需要使用一些统计数学来找出分区的位置。

CREATE PARTITION FUNCTION myRangePF1 (int)
AS RANGE LEFT FOR VALUES (@low, @Med, @High);

对于SQL Server来说,1000万行并不是那么多;常规的索引设计可能可以解决这个问题,而不需要分区。如前所述,尝试在不同的列集合上进行集群;在topicid上进行集群,id看起来像是要测试的东西,特别是在大多数查询都以topicid为标准的情况下。类似这样的聚集索引与分区的效果大致相同,至少它将磁盘上的相关数据行分组在一起,并允许范围扫描快速获取它们。

如果该设计有效,那么您只需要担心插入的碎片,但这是可以管理的。正确建立索引之后,确保有足够的RAM,并且没有磁盘瓶颈。