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

rough"（彻底的）分析，而不是"Fast"（快速）或者"Medium"（适中）;不要选择"Limit the number of workload queries to sample"（将要抽样的工作负荷查询的数目限制为）选项，保留"maximize columns per index"（每个索引的最大列数）设置的最大设置为16;选择所有被用来调优的表。通过选择这些选项，索引调优向导将进行彻底的工作，尽管要花费几个小时才能完成，这依赖于跟踪文件的大小和你执行分析的硬件的速度。注：这些只针对SQLServer2000，SQLServer7.0稍微有些不同。
一旦分析完成，向导也许没有任何建议，也许建议删除一个或更多的索引，或者建议添加一个或更多的索引，或者建议既添加也删除。你需要在采纳建议之前小心评估它们。例如，向导也许建议删除一个特殊的索引，但你知道该索引是真正需要的。那么当你知道这不是一个好想法可为什么向导建议删除呢？这是因为向导没有分析在跟踪文件（仅仅是一个抽样而已）里发现的每一个查询，加之你的抽样跟踪数据可能没有包括需要那个索引的查询。这种情况下，向导也许建议删除该索引，即使这不是一个好的建议。一旦你检查到一个索引是不需要的，你应该删除它。
如果向导建议添加新的索引，那么你要评估它们，也要和目前表上存在的索引比较看看它们是否有意义，会不会引起潜在的新的问题。例如，一个建议的索引或许能帮助一部分查询，但它也可能降低每小时成千上万次的INSERT操作。向导不知道这些，你必须决定哪个更重要，一些查询运行快了点而INSERT去慢了，反之亦然。
最后，即使索引调优向导没有任何新索引的建议，这也不意味着新索引是不需要的，仅仅根据跟踪数据来分析可能不会有任何建议。为了更好的帮助分辨出需要的索引。你要考虑好几天运行多个跟踪以便得到更多的抽样数据。即使那样，索引调优向导也不能找出全部需要的索引，但它将找出所有显而易见需要的索引。
一旦你完成分析并根据建议做出了更改，我建议你再次跟踪分析以便看看你的更改是否有效果。谨记索引调优向导分析不是一蹴而就的事情。随着时间的推移数据库的数据发生了潜在的变化，随着一起变化的还有查询的类型。所以，作为一个要点：定期的对服务器进行跟踪和分析以保持定期的优化。?

每个数据库的每个表都有聚集索引吗？

首要的原则是每个表都应该有聚集索引。聚集索引通常但不总是应该建在单调递增的一列上如自增列，或者其他的值是递增并唯一的列上。大多数情况下，主键是作为聚集索引理想的列。

如果你曾经调优过SQLServer6.5的性能，你也许听说在单调递增列上创建聚集索引不是一个好的方法，因为它可能由于磁盘的"hotspot"（热区）引起性能问题。那个建议在SQLServer6.5中是正确的。

在SQLServer7.0和2000中，"hotspots"通常不是问题了。只有在每秒超过1000个的事务的情况下，"hotspot"才对性能有负面的影响。事实上，"hotspot"在这些环境下是有用的，因为它消除了页拆分。

下面是原因。如果你正在向一个主键上建聚集索引的表里插入新的行，主键是单调递增的，这意味着每个INSERT将在磁盘上逐个的物理顺序出现，因此，页拆分不会发生，这本身就节省了资源。这是因为SQLServer有能力决定数据是否被插入到有单调递增序列的表里，如果是，就不会执行页拆分。

如果你正插入很多行到一个堆表（没有聚集索引的表）中，数据不会按任何特定的顺序插入到数据页，不管数据单调递增与否。这样当从磁盘上访问数据时，SQLServer会花费更多的读操作。另一方面，如果给表添加聚集索引，数据被顺序的插入到数据页上，通常在读取数据时花费更少的磁盘I/O。

如果数据被插入到一个或多或少有随机顺序的聚集索引里，数据通常是随机的插入到数据页里，就象堆表一样，会发生页拆分。

那么说回来，为了全面的提升性能，最好的建议就