为什么我不能简单地添加一个包含所有列的索引？

Question

我在 SQL Server 数据库中有一个表，我希望能够尽可能快地搜索和检索数据。我不关心插入表格需要多长时间，我只关心我可以获取数据的速度。

问题是使用 20 种或更多不同类型的查询访问该表。这使得添加专门为每个查询设计的索引成为一项繁琐的任务。我正在考虑简单地添加一个包含表的所有列的索引。这不是你在“好”数据库设计中通常会做的事情，所以我假设我不应该这样做是有充分理由的。

谁能告诉我为什么我不应该这样做？

更新：我忘了提，我也不关心我的数据库的大小。没关系，这意味着我的数据库大小将增长到超过所需的大小

Answer 1

首先，SQL Server 中的索引在其索引条目中最多只能有 900 个字节。仅此一项就不可能为所有列建立索引。

最重要的是：这样的索引根本没有意义。你想达到什么目的？？

考虑一下：如果您在 (LastName, FirstName, Street, City) 上有一个索引，那么该索引将不能够用于加快对

的查询

• FirstName一个人
• City
• Street

该索引将有助于搜索

• (LastName)，或
• (LastName, FirstName)，或
• (LastName, FirstName, Street)，或
• (LastName, FirstName, Street, City)

但实际上没有别的——如果您只搜索 Street 或只搜索 City，肯定不会！

索引中列的顺序有很大的不同，查询优化器不能只使用索引中间某处的任何列进行查找。

考虑一下您的电话簿：它可能按姓氏、名字或街道排序。那么该索引是否可以帮助您找到您所在城市的所有“Joe's”？所有住在“大街”的人？？不-您可以先按姓氏查找-然后您可以在该组数据中获得更具体的信息。仅仅对所有内容都有一个索引并不能帮助加快搜索所有列的速度根本。

如果您希望能够通过 Street 进行搜索 - 您需要在 (Street) 上添加一个单独的索引（可能还有一两列有意义）。

如果您希望能够通过 Occupation 或其他方式进行搜索 - 您需要另一个特定的索引。

仅仅因为您的列存在于索引中并不意味着会加快对该列的所有搜索！

主要规则是：使用尽可能少的索引 - 对于系统而言，过多的索引可能比完全没有索引更糟糕......构建您的系统，监控其性能，并找到那些花费大多数 - 然后优化这些，例如通过添加索引。

不要仅仅因为你可以就盲目地索引每一列 - 这是对糟糕的系统性能的保证 - 任何索引也需要维护和保养，所以你拥有的索引越多，你的 INSERT、UPDATE 和 DELETE 操作就越多受苦（变慢），因为所有这些索引都需要更新。

Answer 2

您对索引的工作方式存在根本性的误解。

阅读此说明“how multi-column indexes work”。

您可能会遇到的下一个问题是，为什么不创建 one index per column--但如果您尝试达到最佳选择性能，这也是一个死胡同。

您可能会觉得这是一项乏味的任务，但我会说这是一项必需仔细索引的任务。马虎的索引反击，如this example。

注意：我坚信正确的索引是有回报的，而且我知道很多人都有与您相同的问题。这就是为什么我要写一本关于它的免费书。上面的链接引用了可能帮助您回答问题的页面。但是，您可能还想从beginning 阅读它。

Answer 3

...如果您添加一个包含所有列的索引，并且查询实际上能够使用该索引，它将按主键的顺序扫描它。这意味着几乎要创下所有记录。平均搜索时间为 O(n/2).. 与访问实际数据库相同。

你需要阅读很多关于索引的bit。

如果您认为表上的索引有点像 C# 中的字典，这可能会有所帮助。

var nameIndex = new Dictionary<String, List<int>>();

这意味着 name 列被索引，并将返回一个主键列表。

var nameOccupationIndex = new Dictionary<String, List<Dictionary<String, List<int>>>>();

这意味着名称列+职业列被索引。现在想象一下索引包含 10 个不同的列，嵌套的深度到目前为止它包含表中的每一行。

请注意，这并不是它的工作原理。但它应该让您了解如果在 C# 中实现索引是如何工作的。您需要做的是基于广泛查询的一两个键创建索引，这样索引比扫描整个表更有用。

Answer 4

如果这是一个数据仓库类型的操作，其中查询针对 READ 查询进行了高度优化，并且如果您有 20 种剖析数据的方法，例如

WHERE 子句涉及..

 Q1: status, type, customer
 Q2: price, customer, band
 Q3: sale_month, band, type, status
 Q4: customer
 etc

而且您绝对有足够的快速存储空间可供刻录，然后无论如何为每列单独创建一个索引。因此，一个 20 列的表将有 20 个索引，每个单独的列都有一个。我可能会说忽略位列或低基数列，但是既然我们已经走了这么远，为什么还要麻烦（带着那个警告）。他们只会坐在那里搅动 WRITE 时间，但如果你不关心图片的那一部分，那么我们都很好。

分析您的 20 个查询，如果您的热门查询（最热门的查询）仍然不会更快，请使用 SSMS（按 Ctrl-L）在查询窗口中使用一个查询进行计划。它会告诉你什么索引可以帮助查询——只需创建它；全部创建它们，完全记住这会再次增加写入成本、备份文件大小、数据库维护时间等。

Answer 5

我正在考虑简单地添加一个包含表所有列的索引。

这总是一个坏主意。数据库中的索引不是某种神奇的小精灵。您必须分析您的查询，并根据查询的内容和方式 - 附加索引。

这不是“把所有东西都添加到索引然后打个盹”那么简单

Answer 6

1) 大小，索引本质上是在该列中构建数据的副本，一些易于搜索的结构，如二叉树（我不知道 SQL Server 规范）。 2）您提到了速度，索引结构的添加速度较慢。

Answer 7

我认为提问者在问

'为什么我不能做一个类似'的索引'：

create index index_name
on table_name
(
    *
)

问题已经解决了。

但听起来他们正在使用 MS sql 服务器。 了解您可以在索引中包含非键列是很有用的，因此这些列的值可用于从索引中检索，但不能用作选择标准：

create index index_name
on table_name
(
    foreign_key
)
include (a,b,c,d) -- every column except foreign key

我创建了两个包含一百万行相同的表

我这样索引表 A

create nonclustered index index_name_A
on A
(
    foreign_key -- this is a guid
)

还有像这样的表B

create nonclustered index index_name_B
on B
(
    foreign_key -- this is a guid
)
include (id,a,b,c,d) -- ( every key except foreign key)

毫不奇怪，表 A 的插入速度稍快。

但是当我运行这些查询时

select * from A where foreign_key = @guid
select * from B where foreign_key = @guid

在表A上，sql server甚至没有使用索引，它做了一个表扫描，并抱怨缺少索引，包括id、a、b、c、d

在表 B 上，查询速度提高了 50 倍以上，而 io 却少得多

强制 A 上的查询使用索引并没有使其更快

select * from A where foreign_key = @guid
select * from A with (index(index_name_A)) where foreign_key = @guid

Answer 8

该索引将与您的表相同（可能按其他顺序排序）。
它不会加快您的查询速度。