聚集索引与非聚集索引？

聚集索引确定表中数据的物理顺序，并且对于经常搜索值范围的列特别有效。当索引值唯一时，它们对于查找特定行也很有效。

通常（有例外），聚集索引应该位于单调增加的列上 - 例如标识列，或值增加的其他列 - 并且是唯一的。在许多情况下，主键是聚集索引的理想列（但不要将聚集索引放在唯一标识符/GUID 列上。）

从这篇MSDN 文章：

在创建聚集索引之前，了解您的数据将如何被访问。考虑将聚集索引用于：

• 包含大量不同值的列。
• 使用 BETWEEN、>、>=、< 和 <= 等运算符返回一系列值的查询。
• 按顺序访问的列。
• 返回大型结果集的查询。
• 经常被涉及 join 或 GROUP BY 子句的查询访问的列；通常这些是外键列。在 ORDER BY 或 GROUP BY 子句中指定的列上的索引消除了 SQL Server 对数据进行排序的需要，因为这些行已经排序。这提高了查询性能。
• 需要非常快速的单行查找的 OLTP 类型应用程序，通常通过主键进行。在主键上创建聚集索引。

聚集索引不是一个好的选择：

• 频繁更改的列：这会导致整行移动（因为 SQL Server 必须保持行的数据值按物理顺序排列）。在数据往往不稳定的大容量事务处理系统中，这是一个重要的考虑因素。
• 宽键：来自聚集索引的键值被所有非聚集索引用作查找键，因此存储在每个非聚集索引叶条目中。

SQLServerpedia.com 有一些很好的索引调整文章/教程：索引相关的 DMV 查询和使用正确的索引以获得最佳性能。

我读过使用代理键并在该列上使用聚集索引是非常好的做法。通常，这将是一个将自动递增 (IDENTITY) 的 int 列，或者是一个 uniqueidentifier（使其成为顺序 GUID以避免以后出现性能问题！）。

这样做时，您的查询将对跨表的这些代理键执行 JOIN，从而为您提供性能和可伸缩性。

至于其他（非聚集）索引，该选择取决于您的客户如何使用您的应用程序。太多的索引对插入/更新来说意味着灾难。索引不足会减慢读取速度。您需要在两者之间找到平衡。与搜索结合使用的列是索引的逻辑候选，包括复合（多列）索引（在这种情况下请注意列顺序）。

如果您想变得花哨，请拥有一个单独的 OLAP 数据库来报告历史数据。