SQLServer数据库索引性能监控列表

作为索引监控的一部分，检查看看数据库里每个表是否都有索引。如果根本没有索引，认真的考虑给添加一个聚集索引，参考上面的建议。事实上给表添加一个聚集索引不会比没有聚集索引时引起性能下降。?

每个表的任一列是否被多次索引?

听上去这个建议是显而易见的，但它比你认为的要普遍得多，特别是多个DBA每人管理一段时间的数据库。SQLServer不关心你是否这样做，只要索引的名称不同它就认可了。所以当检查表目前的索引时，看看是否有列在不必要的重复索引中。删除它们不仅能节约磁盘空间，也能加快对表数据的访问和修改。?

重复索引的一个通常例子就是忘记了列上有主键，或者列是唯一的，这样列上会自动创建索引，可是又在上面以不同的索引名称创建了索引。

查询里是否有没有被使用的索引?

这里有另外一个显而易见的建议，但也是一个普遍的问题，特别是在数据库正式启用以前DBA或开发人员猜测的为数据库创建的最初的那些索引。仅仅看看表的索引不会告诉你这些索引是否有用，所以分辨没用的索引通常是不容易的。

分辨没用的索引的最好途径是使用索引调优向导，前面讨论过。

不必要的索引，象重复索引，既浪费磁盘空间又对数据的访问修改的性能没有多大的好处。?

索引是否太宽?

索引越宽，明显地就变得越大，访问或修改数据时SQLServer就不得不做更多的操作。因此，你应该避免在太宽的列上添加索引。索引越窄，性能越快。

另外，复合索引，包括两个或更多的列，也可能出现同样潜在的问题。通常要尽可能的避免复合索引。数据库使用复合索引越多，常常意味着数据库的设计有缺陷。

不可能总是避免宽索引或复合索引，但不得不用时，确信对你的选择做过仔细的评估并且没有其他的办法帮助提高性能。?

连接的表的连接列上是否有适当的索引?

基本上，为了最好的性能，表里用来连接的列上都应该建索引。这是直接了当的建议，也是相当显而易见的，但为了最优的JOIN性能监控索引却是不容易的，因为为了全面的性能监控你必须熟悉数据库里所有执行的连接。

当创建主外键关系（通常用来JOIN的）时，很多人都忘记了主键列上会自动创建索引而外键列上不会自动创建，外键列上必须手动创建。

由于经常忘记，作为监控的一部分，你要分辨出表的所有主外键关系并检查每一个外键列上是否有正确的索引。

除此之外，你也能使用索引调优向导帮助分辨出丢失的连接索引，但我发现向导不总是能为连接表分辨出丢失的索引。说穿了，除非你知道数据库里通常运行连接的类型，否则是很难分辨出索引建在哪些列上能获得帮助。

索引是否足够唯一到有用？

仅仅因为一个表有一个或更多的索引并不意味着SQLServer查询分析器会用到它们。在它们被使用之前，查询优化器不得不考虑它们是否有用。如果表的列上不是至少有95％是唯一的，那么查询优化器最可能不用这个列上的非聚集索引。因此，不要给那些没有95％唯一值的列上添加非聚集索引。例如，一个只有"yes"和"no"的列上不是至少95％都是唯一的，在这列上创建索引基本上永远不会得到使用，我们已经知道这对性能有很大的拖累。

作为监控的一部分，考虑在表上目测数据。换句话说，查看表里的数据，再看看索引的那些列。通常，列是否可选来做索引是非常显而易见的。如果你注意到数据都是男或女，是或否等等，那么这些数据不可选来做索引，并且它们上面的任何索引都将浪费空间并影响性能。?

覆盖索引是否带来了好处？

覆盖索引是复合索引的一种形式，包括查询里SELECT、JOIN、WHERE语句引用的所有的列。因此，索引包含了你要查