2

我会在这里感谢 SQL Server 专家的一些建议。让我解释...

我有一个包含 21 列的 SQL Server 2008 数据库表。这是其中的一种快速类型：

  • INT 主键
  • 已经是索引的其他几个 INT（用于引用此表和其他表）
  • 几个 NVARCHAR(64) 来保存用户提供的文本
  • 几个 NVARCHAR(256) 来保存更长的用户提供的文本
  • 几个 DATETIME2
  • 一个 BIGINT
  • 几个UNIQUEIDENTIFIER，一个已经是索引

该表的使用方式是将其作为可排序表呈现给用户，并且用户可以选择对其进行排序的列。该表可能包含数千条记录（如目前有 21,000 条记录，并且还会不断增长。）

所以我的问题是，我是否需要将每一列设置为 INDEX 以实现更快的排序？

PS。忘了说。输出显然支持分页，因此用户一次看到的行数不超过 100 行。

4

3 回答 3

3

与流行的看法相反，仅在列上建立索引并不能保证任何查询都会更快！

如果您经常从该表中使用，则很可能根本不会使用SELECT *..单个列上的这些非聚集索引。

一个好的非聚集索引是一个覆盖索引，这意味着它包含满足一个或多个给定查询所需的所有列。如果您遇到这种情况，那么非聚集索引可能有意义 - 否则，在更多情况下，查询优化器可能会忽略非聚集索引。这样做的原因是：如果您无论如何都需要所有列，则查询必须从非聚集索引到找到的每一行的实际数据（聚集索引）进行键查找 - 键查找是一项非常昂贵的操作，因此，对大量命中执行此操作变得过于昂贵，并且查询优化器将很快切换到索引扫描（可能是聚集索引扫描）来获取数据。

不要过度索引- 使用设计良好的聚集索引，将索引放在外键列上以加快连接速度 - 然后暂时搁置它。观察你的系统，衡量性能，也许在这里或那里添加一个索引 - 但不要只是用大量索引使系统过载！

拥有太多索引可能比没有更糟糕 - 每个索引都必须维护，例如为每个INSERT,UPDATE和DELETE语句更新 - 这需要时间吗？

于 2012-04-08T07:21:48.590 回答
2

这张表......作为可排序的表格呈现给用户...... [可能包含数千条记录

如果您订购了数千条记录以供显示，那么您做错了。典型用户最多可以合理处理500条左右的典型记录。优秀的用户可以处理几千个。不仅如此，您还会误导您的用户，使他们误以为他们已经看到了具有代表性的样本。这会导致糟糕的决策制定和低效的用户工作流程。相反，您需要专注于一个好的搜索算法。

另一个要记住的是，更多的索引意味着更慢的插入和更新。这是一个平衡的行为。Sql Server 保留有关它实际执行的查询和排序的统计信息，并使这些统计信息可供您使用。您可以运行一些查询来准确地告诉您 Sql Server 认为它可以使用哪些索引。我会在没有任何排序索引的情况下进行部署，并让它以这种方式运行一两个星期。然后查看数据并查看用户实际对这些列进行排序和索引。

查看此链接以获取有关查找缺失索引的示例和介绍：http:
//sqlserverpedia.com/wiki/Find_Missing_Indexes

于 2012-04-08T05:41:20.307 回答
0

通常索引用于加速WHERE条件（在某些情况下JOINS）。PRIMARY KEY所以我认为除了加速排序之外不要在列上创建索引。您可以在客户端（如果您使用 win 表单或 wpf）或数据库中进行排序以用于 Web 场景

祝你好运

于 2012-04-08T05:03:22.280 回答