确定是什么导致了坏的索引
现在你知道了什么是好的索引，让我们再研究一下，究竟是什么导致了坏的索引。这里有几点需要注意：
使用了不合适的列；
选择了不合适的数据；
包含了过多的列；
表中包含的记录过少。
6.3.1  使用了不合适的列
如果在表中存在未被查询使用的列，那么最好不要为该列创建索引，除非需要将它同其他的列组合起来创建覆盖索引，正如前面提到的那样。如果为未被查询使用的列设置了索引，索引仍然会增加数据修改操作的开销，但是却不会提高数据提取操作的任何性能。


6.3.3  包含了过多的列
在索引中包含的列越多，在插入或修改数据的时候，被移动的数据就越多。尽管在SQL Server 2008中，对索引数据的更新只需要花费很少的时间，但是如果数据很多，花费的总时间也还是相当可观。因此，在表中所添加的每个索引都可能导致额外的系统开销，所以建议你根据数据提取性能的可接受程度，只创建最少数量的索引。

6.3.4  表中包含的记录过少
从数据性能的观点看，如果在表中只有一行，那么绝对不需要在表中设置索引。SQL Server会在第一个请求中就找到该记录，而不需要索引的帮助，因为SQL Server会使用表扫描。话虽如此，你可能希望包含一个主键，以便强制数据的完整性。
在表中只包含少数记录的时候也同样如此。重申一遍，没有理由为这类表设置索引。其原因如下：SQL Server会先跳转到索引上，它的引擎会对数据进行几次读取，以找到正确的记录，然后会直接通过从索引中提取的记录指针，移动到该记录上。在这个过程中，涉及了好几个动作，并且在SQL Server的不同组件之间进行了多次数据传递。在执行一个查询的时候，SQL Server会确定是使用为表定义的索引来定位要查找的行比较高效，还是只简单通过表扫描来找到要查找的行更快捷。

 

·          

6.4  针对性能对索引进行审查
作为管理员或开发者，你应该经常对表中所构建的索引进行审查，以确保昨天所创建的好索引不会在今天变成坏索引。在构建解决方案的时候，在开发环境中被认为是好的索引，在生产环境中也可能就不那么好了。例如，用户可能会多次执行一个出乎我们意料的任务。因此，强烈建议你专门设置一个任务，以对索引进行长期的监控，了解它们的运行情况。这可以通过SQL Server中的索引优化工具，即数据库引擎优化顾问（Database Tuning Advisor，DTA）来实现。
DTA对数据库和一个保存有代表性信息的工作负荷文件进行观察，并使用这些获取的信息，以关系图的形式显示在数据库中创建了什么索引，以及可以在哪里进行改进。到现在为止，本书中还没有实际介绍如何利用数据工作，因此介绍该工具的使用可能会导致困惑。这种强大且高级的工具只适宜有经验的SQL Server 2008开发者或数据库管理员使用。
要让SQL Server数据库以最优的方式运行，让索引更合理是至关重要的。花一点时间来考虑一下索引，尝试让它们更合理，并定期审查它们。对聚集索引、唯一性索引和那些包含在索引中的列进行审查，以确保尽可能快地提取数据。最后，还应该确保包含在索引中的列具有合理的顺序，以减少SQL Server在查找数据时的读取次数。如果大量的查询都基于在指定的部门或部门的雇员列表中查找人员，那么以列FirstName、LastName和Department这样的顺序来定义索引可能不如以Department、FirstName和LastName这样的顺序来定义索引好。这两种索引之间的不同在于，对于第一种索引来说，SQL Server可能需要进行表扫描才能找到要提取的记录，而对于第二种索引，SQL Server可以对索引进行搜索，直至找到正确的部门，然后只需要从索引中继续返回行，直至部门改变。正如你看到的，第二种方式的工作量更少一些。