我应该创建什么类型的索引？答案

【问题标题】：What type of index should i create?我应该创建什么类型的索引？
【发布时间】：2015-12-31 10:44:14
【问题描述】：

表格有 6 列。 column1 是唯一的，所以我在 column1 上创建了主键并为所有列创建了非聚集索引：

         create primary key for column1
         create index for col2, col3, col4, col5, col6, col1

所以我在 where 子句中的任何列都将使用除 column1 之外的索引，之后它会在主键中丢失 column1 并将两个结果整合。正因为如此，它会提高性能吗？

【问题讨论】：

那么您现在有一个由所有列组成的非聚集索引？好的 - 这可能用于使用 col2 的查询，或使用 col2, col3 的其他查询 - 或使用所有列的查询 - 但它可以 永远不会用于需要col3, col4的查询 - 因为这两列不是 最左边的n列在那个索引中！另外：将所有列添加到索引中总是一个非常糟糕的主意 - 它基本上会复制所有数据，并且很少会产生任何有用的结果......

【解决方案1】：

复合索引由多列组成在 where 子句中。

因此，如果您在(col1, col2, col3, col4) 上有一个索引，则可能会使用该索引

但如果您的查询具有 where 条件，它不能帮助您，例如col3, col4（因为它们不是索引中最左边的 2 列）

所以在你的情况下，你需要一个带有

的索引

没有单一的索引可以满足这些需求 - 例如，如果您在col1, col2, col4 上有一个索引，可能会用于查询#1，但它不能真正用于查询#3（或仅在开始时处理col1 - 但它对col4 没有帮助。

因此，在您的情况下，唯一的选择是拥有 三个单独的索引 - 每种类型的查询一个 - 看看这些是否真的有助于加快查询速度。然而，这也意味着有 三个索引 需要更新和维护，每当表进行插入、更新或删除操作时。尝试并衡量，然后确定速度的提高是否需要插入、更新和删除操作的额外开销。

【讨论】：

我怀疑我的 index1 是否由 column1 和 column4 组成。执行 select * from table1 where column1='some' @marc_s 时是否使用此索引
YES！ 如果您在col1, col4 上有索引，它可用于包含col1=... AND col4 = ... 的查询，但也用于查询有WHERE col1 = ... 一个人。如果您使用 n 最左边的列 - 那么查询优化器将考虑索引
所以，你是说 col1 会考虑 .但 col4 不会考虑。对？ @marc_s 。请确认
如果您在 (col1, col4) 上有一个索引，那么任何在其 WHERE 子句中有 both 列的查询都可能使用该索引 - 任何仅使用 @987654343 的查询也一样@ 在其 WHERE 子句中。但是，如果您的查询只使用 col4，则可以永远使用该索引
好的，我举个例子。请告诉它是否正确。？我将 col1 创建为聚集索引并为所有列创建非聚集索引注意：在非聚集索引中，我将 col1 作为最后的手段。这是最好的主意吗？ bcz 它需要除 col1 之外的所有列进行索引。在它采用聚集索引之后它会整合对吗？ @marc_s

【解决方案2】：

如果您只优化那些查询并且您不关心索引的大小，那么是的完全像这样创建它们 - (col1, col2)、(col3, col4) 和 (col1, col4)。请注意，这里的列顺序并不重要。

但是，如果您有大量数据，或者您经常修改数据（插入、更新密钥或删除），那么您也应该考虑到这一点。重新排列索引也需要时间，列越多，重新排列越多（sql server 的选项越少）。索引也占用空间，因此如果您有大数据（以及限量版或磁盘），那么您可能还需要优化空间。

然后您可以选择权衡解决方案并仅创建两个索引(col1) 和(col4)，这将部分覆盖所有三个查询。这完全取决于col1 和col4 的选择性以及您调用查询的频率以及您需要查询的速度。

要了解基础知识，请参阅best guide 以获取那里的索引。

【讨论】：

列的顺序 IS 很重要，因为它决定了索引可能用于哪些其他可能的查询。如果您在 (col1, col4) 上有索引 - 那么这也可能用于仅在 col1 上的查询 - 但 NOT 仅用于在 col4 上的查询。复合索引的列顺序非常很重要！
@marc_s 确定顺序很重要，但不是here，我的意思是question中的查询。
同意 - 对于这三个查询，它不是 - 但您应该始终超越当前拥有的内容，看看您是否可以针对未来和其他要求优化索引
@marc_s 可以说是附加的，而不是未来的（除非你知道并且我在你面前鞠躬：）。