在 SQL Server 2008 中对非分区表进行分区
我有一个表,我认为该表将从分区中受益:
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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这是有道理的。
分区键将是外部 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.