在 SQL Server 2008 中对非分区表进行分区

发布于 2024-11-09 23:53:59 字数 528 浏览 4 评论 0原文


我有一个表,我认为该表将从分区中受益:

CREATE TABLE [dbo].[my_table](
[id] [int] IDENTITY(1,1) NOT NULL,
[external_id] [int] NOT NULL,
[amount] [money] NOT NULL,
    PRIMARY KEY CLUSTERED ([id] ASC));

每个表只有几个不同的 external_id 和数千条记录。
SSMS 创建分区向导生成一个我不完全理解的脚本。创建分区函数和分区模式后,
--它会删除主键,
--然后在id上再次创建主键,这次是非聚集的,
--然后在新创建的分区架构上的 external_id 上创建聚集索引,
--最后它会删除上一步创建的聚集索引。

除了最后一步之外的所有内容似乎都很清楚,但我不明白为什么它必须删除聚集索引。我应该从批次中删除最后一步吗?

任何帮助将不胜感激。

I have a table which in my opinion will benefit from partitioning:

CREATE TABLE [dbo].[my_table](
[id] [int] IDENTITY(1,1) NOT NULL,
[external_id] [int] NOT NULL,
[amount] [money] NOT NULL,
    PRIMARY KEY CLUSTERED ([id] ASC));

There are just few different external_id and thousands of records for each of them.
SSMS Create Partition Wizard generates a script that I don't completely understand. After creating partition function and partition schema,
--it drops Primary Key,
--then creates Primary Key again on id, this time as non-clustered,
--then creates clustered index on external_id on newly created partition schema,
--and finally it drops the clustered index created on previous step.

Everything except last step seems clear, but I cannot get why it has to drop the clustered index. Should I remove the last step from the batch?

Any help will be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

人事已非 2024-11-16 23:53:59

这是有道理的。

分区键将是外部 ID,因此聚集索引必须包含该 ID。

它将主键保留在非聚集索引中 - 因为它位于 ID 而不是 external_id 上。

它在 external_id 上创建聚集索引以将数据物理移动到分区方案中。

它会删除聚集索引,因为它仅使用它来移动数据 - 它不是先前指定的索引。

有多种替代方案,假设您始终知道 external_id,那么您可以选择将聚集索引创建为 (id,external_id) - 用于表的分区架构/函数字段必须位于分区架构上的聚集索引内。

从性能角度来看,这不会带来巨大的提升,它的用途更多的是您可以轻松删除整个 external_id,而不是大型删除事务。

It makes sense.

The partition key is going to be the external id, so the clustered index must include that.

It preserves the primary key in a non-clustered index - since it's on ID not external_id

It created the clustered index on external_id to physically move the data into the partition scheme.

It drops the clustered index since it only used it to move the data - it was not a previously specified index.

There are a number of alternatives, assuming you always know the external_id, then you could choose to create the clustered index as (id,external_id) - the partition schema / function field used for the table must be within the clustered index on the partition schema.

Performance wise, this is not going to be a huge boost, the use of it is more that you can drop an entire external_id trivially, instead of a large delete transaction.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文