技巧2：分析索引

　　一旦理解了数据，接着就可以设计或重新设计索引了。在SQL Server 2000 Books Online中，有一篇不错的关于索引设计的文章，建议大家可以去阅读一下。首要的一条规则是，索引必须基于JOIN条件，以及WHERE、ORDER BY 和GROUP BY子句中使用的字段。阅读该文章以获得其它的推荐。

　　CRUD图表（创建、读取、更新、删除）也可以帮助我们理解数据访问所需要的索引实现方式。虽然建立一个CRUD图表是一项艰难的任务（很多人甚至都不知道如何着手），但是，为关键的表创建一个CRUD图表可能有助于整体索引；因为大多数的系统都有与表子集有关的性能问题，所以关注这些问题将可以最小代价地实现性能的提高。下面是一个执行存储过程特殊操作（JOIN、WHERE、ORDER BY等）的表（Customer）的CRUD图表示例：

　　这个图表提供了每一表上的索引的科学理解。从这些数据中，我们需要根据事务的类型来平衡索引需要，这不仅是一个艺术形式。典型地，索引可以提升SELECT命令性能，但是它们可能影响INSERT、UPDATE或DELETE语句性能，因为在这些操作中，SQL Server必须维护索引，这需要额外的开支。

　　数据的另外一个重要的方面是索引重建的频率（日、周、月、季度、年以及从不）。索引重建的频率越高，索引方法就越积极。如果系统需要在接下来的三年中24小时/7天地运行以支持一个功能，那么索引的设计一定不同于每周重建索引来支持多个功能的数据库。尽管如此，系统并不是不变的，它们是随着业务需求的改变而改变的。因此对这些进行计划或修正会在将来遇到问题时更主动一些的。

　　技巧3：理解如何创建索引

　　SQL Server有两种索引：聚簇索引和非聚簇索引。我将使用前面的两个来自SQL Server 2000 Books Online的详细信息来探讨这个话题。简单而言，一个表可以没有索引、有一个聚簇索引、一个聚簇索引和一个非聚簇索引，或者只有非聚簇索引。可以为每个表创建一个聚簇索引，然后数据将会根据这个字段来物理地排序。对于没有聚簇索引的表，数据将根据数据项的顺序存储的。

　　CREATE INDEX的两个与索引碎片相关的主要配置是：

• FILL FACTOR——确定叶级（数据）页的填充程度。
• PAD_INDEX——确定中间级（从索引到数据页的指针）页填充的程度，典型的情况下，它与FILL FACTOR的值是一样的。

　　如果我们无法确定在特定的间隔（如，日、周、月、季度、半年度、年度等等）中碎片的程度，那么最好把开始的填充因数配置为80%。监测碎片以便确定基于每个表聚簇索引的理想配置；它所需要的存储量会与配置为5%到10%时有很大的不同。填充因数越低（如，40%到50%），所需要的存储空间就越大，并且索引需要扫描或查找更多的页以满足查询需要。填充因数越高（90%到100%），所需要的存储空间就越小，并且需要扫描的页面就越少，但是页拆分的开销会导致性能降低和索引碎片。有什么好建议呢？寻找理想的填充因数来避免页拆分和碎片，同时还不会导致过大数据库存储空间。