恰当的索引能创建完全不同的性能。对于大多数的数据类型，SQL Server只支持两种索引类型——聚簇索引和非聚簇索引。同时，SQL Server也支持全文索引和XML索引，但是它们只与特定数据类型相关。

　　为聚簇索引选择恰当的字段或字段集是至关重要的。这是因为表的数据是根据聚簇索引字段的值而物理地排序的。每个表上只能创建一个聚簇索引。非聚簇索引引用聚簇索引的键（数据值）来确定每个记录的物理位置。

　　一般推荐在不会频繁修改的、经常会被查询的和有瘦数据类型的字段上创建聚簇索引。在大多数情况下，在标识字段上的聚簇索引是最佳的，因为标识值是最常被查询的——每个记录都有一个唯一的标识值——同时它们从不用更新，而且是使用SMALLINT、INT或BIGINT数据类型创建的。

　　然而，通常情况下是不会有一个表从来不被基于它的标识字段查询的。如果真有，我们就需要仔细考虑数据通常是如何检索的，可能是通过指向另外一个表的外键或者一个字符字段。通常情况下，通过在最常用来检索数据的字段或字段集上创建聚簇索引可以提高性能。

　　有些开发人员倾向于创建组合聚簇索引。它们都包括几个字段，是一个唯一标识每个记录的组合。听起来可能是一个很好的实践方法，因为标识字段没有业务意义，而其它的字段——如入职日期、部门名称和车辆识别码——一定可以被应用用户快速理解。然而，对性能而言，我们必须避免使用组合聚簇索引。

　　再次，越瘦的索引，SQL Server可以越快地扫描或查找。对于一个小的数据集，组合索引的性能相对更好些。但是，随着用户数增加，它将会出现更多的问题。

　　建立恰当的索引可以提高性能，我们也许会觉得工作已经完成了。但是，随着表中数据的添加、修改和删除，各个索引会出现碎片。碎片的程度越高，索引的效率就越低。因此，现在我们需要实现一个将索引中的碎片删除的计划，以便确保索引的有效性。

　　对于先前的SQL Server版本，从大索引（有数百万行的表）中删除碎片往往需要停机。幸运的是，SQL Server 2005支持在线索引重建。然而，记住，重建索引仍然需要占用系统资源和数据库的tempdb空间。可能的话，调度索引维护在活跃用户最少的时间进行。

　　SQL Server数据库架构师和管理员可以选择多种方法来使他们的应用在一开始就表现良好。为了保证成功的数据库性能，在设计阶段作出很好的选择非常重要。在这个版本的SQL Server INSIDER中，专家Baya Pavliashvili探讨了如何作出可以优化性能的数据库设计决定。设计一个数据库包括合适的：

　　• 数据模型
　　• 数据类型
　　• 索引策略
　　• 代码模块
　　• 高可用选项