1

编辑：我添加了“Slug”列来解决特定记录选择的性能问题。

我的表格中有以下列。

Id Int - Primary key (identity, clustered by default)
Slug varchar(100)
...
EntryDate DateTime

大多数时候，我按 EntryDate 订购 select 语句，如下所示。

Select T.Id, T.Slug, ..., T.EntryDate
From (
    Select Id, Slug, ..., EntryDate,  
        Row_Number() Over (Order By EntryDate Desc, Id Desc) AS RowNum
    From TableName
    Where ...
) As T
Where T.RowNum Between ... And ...

如果有重复的EntryDates，我将按EntryDate 和Id 对其进行排序。

当我选择 A 记录时，我执行以下操作。

Select Id, Slug, ..., EntryDate
From TableName
Where Slug = @slug And Year(EntryDate) = @entryYear 
    And Month(EntryDate) = @entryMonth

我有一个独特的 Slug & EntryDate 键。

在我的情况下，什么是键和索引的明智选择？我面临性能问题可能是因为我按未聚集索引的列排序。

我应该将 Id 设置为非聚集主键并将 EntryDate 设置为聚集索引吗？

我感谢您的所有帮助。谢谢。

编辑：

我没有尝试在 EntryDate 上添加非聚集索引。从后端插入的数据，因此插入的性能对我来说没什么大不了的。此外，EntryDate 并不总是插入日期。它可以是过去的日期。后端用户选择日期。

4

5 回答 5

1

根据当前的表布局，您需要一些这样的索引。

CREATE INDEX IX_YourTable_1 ON dbo.YourTable
(EntryDate, Id)
INCLUDE (SLug)
WITH (FILLFACTOR=90)

CREATE INDEX IX_YourTable_2 ON dbo.YourTable
(EntryDate, Slug)
INCLUDE (Id)
WITH (FILLFACTOR=80)

将您要返回的任何其他列添加到 INCLUDE 行。

将您的第二个查询更改为类似的内容。

Select Id, Slug, ..., EntryDate
From TableName
Where Slug = @slug 
    AND EntryDate BETWEEN CAST(CAST(@EntryYear AS VARCHAR(4) + CAST(@EntryMonth AS VARCHAR(2)) + '01' AS DATE) AND DATEADD(mm, 1, CAST(CAST(@EntryYear AS VARCHAR(4) + CAST(@EntryMonth AS VARCHAR(2)) + '01' AS DATE))

当前编写第二个查询的方式永远不会使用索引。如果您可以将 Slug 列更改为相关表，它将提高您的性能并降低您的存储需求。

于 2009-02-06T22:01:39.910 回答
0

您是否尝试过在 entrydate 上简单地添加一个非聚集索引来查看您获得了什么样的性能提升？

此外，多久添加一次新数据？添加的新数据是否总是>=最后一个EntryDate？

于 2009-02-06T18:41:53.463 回答
0

您希望将 ID 保留为聚集索引，因为您很可能会从您的 id 加入表，而不是进入日期。

一个只有日期字段的简单非聚集索引可以加快速度。

于 2009-02-06T18:47:52.217 回答
0

集群有点像“索引分页”，索引是“分块”的，而不是简单的长列表。当您拥有大量数据时，这很有帮助。数据库可以在集群范围内搜索，然后找到单个记录。它使索引更小，因此搜索速度更快，但不太具体。一旦在集群中找到正确的位置，它就需要在集群中进行搜索。

大量数据时速度更快，但数据集较小时速度较慢。

如果您不使用主键进行大量搜索，则对日期进行聚类并将主键保留为非聚类。这实际上取决于您的查询与加入其他表的复杂程度。

于 2009-02-06T18:49:41.090 回答
0

如果您要返回一堆记录，并且您返回的某些字段不是索引的一部分，则聚集索引只会产生任何影响。否则没有任何好处。

您需要首先找出查询计划告诉您当前查询速度慢的原因。没有它，它主要是无用的推测（这在优化查询时通常会适得其反。）

如果没有可靠的查询计划可以比较，我不会尝试任何事情（由我或其他人建议），至少要知道你是在做善事还是在做坏事。

于 2009-02-06T22:15:10.177 回答