相关疑难解决方法(0)

我公司一直致力于使用我们Azure的SQL数据库表的GUID作为主键的罪(它实际上是比这更糟糕:我们使用VARCHAR(36),而不是唯一标识符).因此,我们最终得到碎片索引.它们看起来像这样:

CREATE TABLE OldTable (
  Id VARCHAR(36) PRIMARY KEY CLUSTERED NOT NULL DEFAULT NEWID(),
  CreateTime DATETIME2 NOT NULL,
  ...
)

我通过创建新表"修复"了这个问题.这一次,我为CLUSTERED INDEX使用了一个不可变的,不断增加的DATETIME2(例如CreateTime)列,并将VARCHAR(36)保持为PRIMARY KEY,但这次是NONCLUSTERED.像这样:

CREATE TABLE NewTable (
  Id VARCHAR(36) PRIMARY KEY NONCLUSTERED NOT NULL DEFAULT NEWID(),
  CreateTime DATETIME2 NOT NULL INDEX IX_NewTable_CreateTime CLUSTERED,
)

然后我使用INSERT INTO NewTable SELECT*FROM OldTable将旧表中的行"复制"到新表中.最后,我重命名表并删除旧表.生活似乎很好.

令我惊讶的是,几周之后,我发现NewTable有许多碎片索引,平均碎片率高达80%!甚至IX_NewTable_CreateTime也报告了18%的碎片.

INSERT INTO是否将索引分散？请问REBUILD指数能解决问题吗？