关于SQLServer中索引使用及维护简介

在应用系统中，特别是在联机事务处理中，数据查询和处理的速度已经成为衡量应用系统成败的标准。使用索引来加速数据处理已经成为大多数数据库用户接受的优化方法。
在良好的数据库设计基础上，索引的有效使用是SQLServer实现高性能的基础。SQL Server采用基于成本的优化模型，该模型决定是否使用索引或对每个提交的表查询使用哪些索引。因为查询执行的大部分开销是磁盘I/O，所以使用索引来提高性能的主要目标之一是避免全表扫描，因为全表扫描需要从磁盘读取表的每个数据页。如果有指向数据值的索引，查询只需要读几次磁盘。因此，如果建立了合理的索引，优化器可以使用索引来加快数据查询过程。但是索引并不总是提高系统的性能，索引的存在加上删除修改都会增加一定的工作量。因此，在适当的地方添加适当的索引，从不合理的地方删除次优索引，将有助于优化那些性能较差的SQLServer应用程序。实践表明，合理的索引设计是建立在对各种查询的分析和预测基础上的，只有将索引与程序正确地结合起来，才能产生优化的方案。本文对SQLServer索引的性能进行了分析和实践。

一、聚集索引的使用

簇索引是一种对磁盘上的实际数据进行重新组织，以便按一列或多列的指定值进行排序。因为聚集索引的索引页指针指向数据页，所以使用聚集索引查找数据几乎总是比使用非聚集索引更快。每个表只能建立一个聚集索引，建立聚集索引至少需要120%的额外空空间来存储表和索引中间页的副本。构建聚集索引的想法是:

1.大多数表应该有聚集索引或使用分区来减少页脚页的竞争。在高事务环境中，阻塞最后一页会严重影响系统的吞吐量。

2.在聚集索引下，数据按物理顺序排列在数据页上，重复值也排列在一起。因此，在那些包含范围检查(between，=)或使用group by或order by的查询中，一旦找到了范围中第一个键值的行，就保证了后续索引值的行在物理上是连续的，无需进一步搜索，从而避免了大规模扫描，大大提高了查询速度。

3.在insert操作频繁的表上建立聚集索引时，不要建立在单调向上增值的列上(如IDENTITY)，否则往往会造成阻塞冲突。

4.不要在聚集索引中包含频繁修改的列，因为修改代码值后，数据行必须移动到新位置。

5.选择聚集索引应该基于where子句和联接操作的类型。

聚集索引的候选列有:

1.主键列，在where子句中使用，随机插入。

2.按范围访问的列，如pri_order > 100和pri_order < 200。

3.分组依据或排序依据中使用的列。

4.不经常修改的列。

5.联接操作中使用的列。

第二，非聚集索引的使用

默认情况下，SQLServer建立的索引是非聚集索引。因为非聚集索引不重新组织表中的数据，所以它存储每行的索引列值，并用指针指向数据所在的页。换句话说，非聚集索引在索引结构和数据本身之间多了一层。如果一个表没有聚集索引，它可以有250个非聚集索引。每个非聚集索引为访问数据提供了不同的排序顺序。建立非聚集索引时，要权衡加快查询速度和降低修改速度的利弊。此外，应该考虑这些问题:

1.应该使用多少个空索引？

2.适当的列是否稳定。

3.如何选择索引键，扫描效果是否更好。

4.是否有许多重复值。

对于频繁更新的表，表上的非聚集索引比聚集索引需要更多的开销，并且根本不需要索引。对于移动到新页的每一行，指向数据的每个非聚集索引的页级行也必须更新，有时可能需要对索引页进行排序。从页面中删除数据的过程也有类似的开销。此外，删除过程必须将数据移动到页面顶部，以确保数据的连续性。因此，建立非聚集索引应该非常谨慎。非聚集索引通常用于以下情况:

1.列通常用于聚合函数(如Sum、...).

2.列通常用于连接、排序和分组。

3.搜索到的数据不超过表中数据的20%。