小编dar*_*ect的帖子

我正在重新考虑我对表主键的选择，并希望得到一些输入。

一些上下文：我们正在构建一个 REST API，客户端可以在其中访问由 GUID 标识的“资产”。因此，我们数据库中的 Asset 表类似于：

CREATE TABLE [dbo].[Asset](
    [Id] [uniqueidentifier] NOT NULL,
    [TypeId] [int] NOT NULL,
    [Date] [datetime] NOT NULL,
    [Title] [varchar](1000) NULL,
    [Description] [varchar](max) NULL,
    [Created] [datetime] NOT NULL,
    [Modified] [datetime] NOT NULL,
    [PublisherFields] [xml] NULL,
    [StatusId] [int] NOT NULL,
 CONSTRAINT [PK_Asset] PRIMARY KEY CLUSTERED 
(
    [Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

我们在使用这种结构时遇到了一些问题，特别是表上的聚集索引很快变得碎片化，现在我们已经达到了无法重建它的程度（因为 Azure 对查询时间的限制）。

进一步的研究表明，使用 uniqueidentifier 作为聚集索引并不总是一个好的选择，因为 newid() 不会按顺序生成 ID（除非您使用 newsequentialid()，但 Azure …

昨天，我们将 Azure 中的一个数据库从旧的商业版扩展到了新的标准版 (S2)。

从那以后，它的行为一直很不稳定。

我们有一个相对简单的表，称为 dbo.Asset。在它上面有一个名为 ContentSetId 的列，它是整数类型。此列也包含在索引中：

CREATE NONCLUSTERED INDEX [IX_Asset_ContentSet] ON [dbo].[Asset]
(
    [ContentSetId] ASC
)

该表包含大约 200 万条记录。

下面的查询第一次运行需要 36 秒，但后续运行需要 0 秒。我们在其他查询中也看到了类似的行为，它们可能需要一分钟以上的时间才能返回 1000 行以下，但随后的运行速度要快得多。

SELECT TOP 100 * FROM dbo.Asset WHERE ContentSetId = 3

如上所述，自从从商业版更改为新标准 s2 以来，我们才注意到这种行为。

任何建议将非常受欢迎！