我很欣赏SQL Server大师的一些建议。让我解释一下......
我有一个包含21列的SQL Server 2008数据库表。这是一个快速类型：
使用此表的方式是将其作为可排序表呈现给用户，并且用户可以选择对其进行排序的列。这个表可能包含数千条记录（比如目前它有21,000条记录，并且它将会增长。）
所以我的问题是，我是否需要将每列设置为INDEX以实现更快的排序？
PS。忘了说。输出显然支持分页，因此用户一次只能看到100行。
答案 0 :(得分：3)
与流行的看法相反，只是在列上有索引不保证任何查询都会更快！
如果您经常使用该表中的SELECT *..，那么单个列上的这些非聚集索引很可能根本不会使用。
良好的非聚簇索引是覆盖索引，这意味着它包含满足一个或多个给定查询的所有必要列。如果您遇到这种情况，那么非聚簇索引可能有意义 - 否则，在更多情况下，查询优化器可能会忽略非聚簇索引。原因是：如果您仍需要所有列，则查询必须从非聚集索引执行键查找到找到的每一行的实际数据（聚簇索引） - 以及键查找是一项非常昂贵的操作，因此对于大量命中执行此操作会变得过于昂贵，并且查询优化器将很快切换到索引扫描（可能是聚簇索引扫描）来获取数据。
不要过度索引 - 使用设计良好的聚簇索引，将索引放在外键列上以加速连接 - 然后让它暂时使用。观察你的系统，测量性能，可能在这里或那里添加一个索引 - 但不要只是用大量的索引使系统超载！
索引太多可能比没有索引更糟糕 - 必须维护每个索引，例如针对每个INSERT，UPDATE和DELETE声明进行了更新 - 这需要时间！
答案 1 :(得分：2)
此表是...作为可排序表呈现给用户... [可]包含数千条记录
如果您要订购数千条记录进行展示，那么您做错了。典型用户可以合理地处理最多约500条典型记录。特殊用户可以处理几千个。除此之外，还有误导用户，误导他们看到了代表性的样本。这导致糟糕的决策制定和低效的用户工作流程。相反，你需要专注于一个好的搜索算法。
另外要记住的是，更多的索引意味着更慢的插入和更新。这是一种平衡的行为。 Sql Server会统计它实际执行的查询和排序，并使这些统计信息可供您使用。您可以运行查询，告诉您Sql Server认为可以使用的索引。我会在没有任何排序索引的情况下进行部署，让它以这种方式运行一到两周。然后查看数据并查看用户实际排序的内容并仅为这些列编制索引。
请查看此链接以获取有关查找缺失索引的示例和简介：
http://sqlserverpedia.com/wiki/Find_Missing_Indexes
答案 2 :(得分：0)
通常，索引用于加速WHERE条件（在某些情况下JOINS）。因此，除了PRIMARY KEY加速排序之外，我不认为在列上创建索引。您可以在客户端（如果使用win表单或wpf）或在数据库中进行Web场景排序
祝你好运