我有一个旧数据库,不幸的是,在设计最大的表之一时做出了选择,其中包含照片(称为“照片”的表)并且具有“uniqueidentifier”类型的 PK。该表有 195k 行,显然碎片率接近 100%。我想在这张桌子上建立一个新的PK,但有一些问题和注意事项
数据背景: 表的行大小预计不会超出 (int) 的范围。此外,与“照片”表的 PK 不存在 FK 关系。如前所述,“照片”表中有 195k 行。有一个潜在的考虑因素:“Photos”中有一个名为“Job_ID”的非唯一列,它与另一个名为“DeliveryTicket”的表的 PK 具有 FK 关系。该键的本质是一个递增计数器 (int)。表“DeliveryTicket”上的 PK“Job_ID”与表“Photos”上的 FK“Job_ID”之间存在一对一的关系。
我的担忧源于碎片化和索引的角度,我的问题是:
如何将新列“New_ID”添加到“照片”,并将 PK 约束设置为非空,并使用类型 (int) 的新递增索引填充现有行?
我应该以及如何在“照片”表的 FK 值上创建新的聚集索引?请注意,通过程序逻辑,对“照片”表的大多数查询将针对 FK 值“Job_ID”,但绝不会针对“照片”表的现有或任何新 PK。表“Photos”最快的索引将位于 FK 关系列“Job_ID”上。
是否有更好的方法来创建一个新的 PK,从“Job_ID”的最低(“照片”上非唯一)值开始计数,这样默认索引(PK)将是最快的索引?
以下是照片创建表的示例:
CREATE TABLE [dbo].[Photos](
[ID] [uniqueidentifier] ROWGUIDCOL NOT NULL,
[Photo_Serial_Number] [int] IDENTITY(1,1) NOT NULL,
[Job_ID] [int] NOT NULL,
[Photo_Upload_Disposition_Type] [int] NOT NULL,
[NET_Rating] [real] NULL,
[Rating_ID] [int] NULL,
[Image_Data] [varbinary](max) FILESTREAM NOT NULL,
[File_Name] [nvarchar](50) NOT NULL,
[File_Extension] [varchar](5) NOT NULL,
[Image_Comments] [nvarchar](1000) NULL,
CONSTRAINT [PK_Photos] PRIMARY KEY CLUSTERED
我正处于探索阶段。这是一个生产数据库,虽然它将被备份并测试更改,因为它必须在维护窗口期间发生,但尚未进行此类更改。
该表有 195k 行,显然几乎 100% 碎片。
那又怎样?您有可衡量的性能问题吗?您可以简单地添加默认值 NEWSEQUENTIALID 来生成顺序 GUID,以减少未来的碎片。
谢谢大家的快速回复。我认为这是一个严重的菜鸟问题,正如 @siggemannen 暗示的那样,我正在处理的查询(虽然不是 *)确实包含 varbinary。我没有注意到查询中有这个。我得检查一下程序。
我认为目前没有必要构建新的 PK,或解决碎片化问题,但如果经过审查后认为有必要,我将采用 PK 综合体作为建议。
很抱歉提出新手问题,也希望大家提出建议。