【问题标题】:What is the proper use of a clustered index?聚集索引的正确用途是什么?
【发布时间】:2016-01-12 16:14:58
【问题描述】:

我可能没有正确地提出这个问题。通过使用,我并不是指我应该在何时何地在桌子上创建一个——这将是一个过于宽泛的问题。

我的意思是,一旦我创建了一个聚集索引,它会总体上提高性能还是我需要在查询中使用关联的列来获得性能提升?

这是一个示例:假设我创建了一个包含以下列的表; RowNum、FileId、名称和日期。我创建为标识列的 RowNum 并应用聚集索引。但是,在实践中,通常使用 FileId 查询表。例如:

SELECT
    FileId, 
    Name
FROM MyTable
WHERE FileId IN ('11101101', '11101201', '11101301')

由于查询中没有使用 RowNum,我是否还能从索引中获得任何性能优势?

如果这是一个基本问题,请提前道歉。我一直在阅读约束和索引,我想确定我理解它们。这似乎是我阅读的所有内容中都掩盖的一点。

编辑:我想我已经得到了答案。或者至少与我将获得的明确答案一样接近。

让我稍微重申一下这个问题:我试图解决的是假设我有一个包含三列的表,rowNum、Id 和 Name。该表通常会根据 Id 或 Name 进行查询,让我们更进一步说,我们将在每一列上都有非聚集索引。我的问题是,在这种情况下,rowNum 上的聚集索引是否会提高使用其他列的查询的性能。

据我所知,答案是肯定的,但您可能需要考虑将聚集索引放在另一列上。

这是一个非常广泛的问题,我很欣赏大家提供的见解。我已经接近一个好的答案,因为我将获得相关事实,而且我现在对索引更加了解。再次感谢!

【问题讨论】:

标签: sql-server tsql clustered-index


【解决方案1】:

如果表有一个自然主键,那么它是聚集索引的一个很好的候选者。

在您的情况下,RowNum 是聚集索引上的身份 PK。这有利于按 RowNum 查找行,也有利于连接。

有时您会看到查询中使用的 PK 或其他索引甚至看起来都没有使用该列。

您发布的查询将受益于 FileId 上的非聚集索引。

如果 FileId 是唯一的,则考虑将其用于 PK 并跳过 RowNum。

【讨论】:

    【解决方案2】:

    简短的回答是你需要有 1 个!每张表都有聚集索引,而且经常是PK。如果 PK 是计数器,则 PK 是正确的候选者(意味着新行将位于表的末尾)。关于 SO (like this one) 和网络上有很多关于此的讨论。

    【讨论】:

    • 不,您不需要为每个表拥有一个聚集索引。 没有有一个也有原因。
    • 不知道为什么你被否决了。我不知道有人真的明白我直接问的问题,但这个答案让我走上了正确的道路,所以我会标记它。
    • 而 PK 通常不是聚集索引的最佳候选者
    【解决方案3】:

    许多关于性能和索引的问题,正确答案是:这取决于

    聚集索引意味着您的表将按该列“物理”排序(这就是为什么表中只能有一个聚集索引)。这也是为什么对该索引使用非顺序值列是一个坏主意的原因。

    同样在 MSSQL Server 中,如果您在一个表中有一个唯一的聚集索引,那么您创建的任何其他索引都将包含该聚集索引。

    一般来说...

    当您对其列进行大量过滤/排序时,聚集索引非常适合选择。

    在@Frisbee 评论之类的自然键或代理键上使用它也是很常见的。

    聚集索引不利于插入/更新,并且当您更改聚集索引列上的值/插入而不是顺序值时非常糟糕,因为引擎会尝试保持索引 B 树的平衡和有序.

    确保您以正确方式使用索引的唯一方法是对其进行酸测试(使用臃肿的数据库)并研究其实际查询计划。

    我建议您寻找MSDNSQL Server Central 之类的网站,并了解有关索引的更多信息,因为这个主题对于这个答案来说太宽泛了。

    【讨论】:

      猜你喜欢
      • 2021-10-17
      • 2016-07-04
      • 2010-11-18
      • 2012-12-21
      相关资源
      最近更新 更多