3.6 小结
在SQL Server或任何其他数据库环境中，索引是一种基础性的主题，因而绝不要轻视。它们既能导致良好的性能，也能导致糟糕的性能。
关于索引要考虑的首要问题是：
l 聚集索引通常比非聚集索引快（几乎可以说总是比非聚集索引快，不过有例外的情况）；
l 在将获得高级别选择性（即95%或更多的行是唯一的）的列上，只放置非聚集索引；
l 所有的数据操作语言（DML：INSERT、UPDATE、DELETE、SELECT）语句都能从索引中受益，但是索引会让插入、删除或更新（记得前面讲过，更新使用删除和插入的方法）变慢。索引对查询的查找部分很有帮助，但是任何对数据的修改将需要做额外的工作（除了实际的数据外还要维护索引）；
l 索引会占用空间；
l 只有当查询引用了索引中的第一列时，才会使用索引；
l 索引既能有助益，也能带来麻烦——要了解为什么要创建索引，并且不创建不需要的索引；
l 索引能为非结构化的XML数据提供结构化的数据性能，但要记住，与其他索引一样，这会涉及开销的问题。
在考虑索引时，问自己下面这些问题：
|
问 题 |
回 答 |
|
会对该表进行大量的插入和修改吗？ |
如果答案是肯定的，则尽量少用索引。通常，这种类型的表通过主键的单记录查找完成修改——这往往就是该表上唯一需要的索引。如果插入操作是不连续的，那么，考虑不使用聚集索引 |
|
这是一个报表吗？即是说，这里没有多少插入，但会以多种不同的方法运行报表吗？ |
多数索引是不错的。把聚集索引确定在经常使用的可能会在范围中提取的信息上。OLAP系统中的索引数目常常是OLTP环境中的数倍 |
|
数据上有高级别的选择性吗？ |
如果是，并且它常常是WHERE子句的目标，那么添加索引 |
|
已经删除了不再需要的索引吗？ |
如果没有，为什么不删除？ |
|
制定了维护策略吗？ |
如果没有，为什么不制定？ |