索引优化建议

优化数据库性能

索引优化建议

Microsoft® SQL Server® 2000 查询优化器在多数情况下可靠地选择最高效的索引。总体索引设计策略应为查询优化器提供更多的索引选择机会，并支持其做出正确的决定。这在各种情形下可减少分析时间并取得较好的性能。

不要总是将使用索引等同于好的性能，反之亦然。如果使用索引总能产生最佳性能，查询优化器的工作就太简单了。实际上，不正确的索引检索选择会导致比最佳性能差的结果。因此，查询优化器的任务是只在索引检索能提高性能时才选择使用索引检索，在其妨害性能时则避免使用。

关于创建索引的建议如下：

将更新尽可能多的行的查询写入单个语句内，而不要使用多个查询更新相同的行。仅使用一个语句，就可以利用优化的索引维护。

使用索引优化向导分析查询并获得索引建议。有关更多信息，请参见索引优化向导。

对聚集索引使用整型键。另外，在唯一列、非空列或 IDENTITY 列上创建聚集索引可以获得性能收益。有关更多信息，请参见使用聚集索引。

在查询经常用到的所有列上创建非聚集索引。这可以最大程度地利用隐蔽查询。有关更多信息，请参见使用非聚集索引。

物理创建索引所需的时间在很大程度上取决于磁盘子系统。需要考虑的重要因素包括：

用于存储数据库和事务日志文件的 RAID（独立磁盘冗余阵列）等级。

磁盘阵列中的磁盘数（如果使用了 RAID）。

每个数据行的大小和每页的行数。这将决定为创建索引须从磁盘读取的数据页的数目。

索引中的列数和使用的数据类型。这将决定必须写入磁盘的索引页的数目。

检查列的唯一性。有关更多信息，请参见使用唯一索引。

在索引列中检查数据分布。通常情况下，为包含很少唯一值的列创建索引或在这样的列上执行联接将导致长时间运行的查询。这是数据和查询自身的基本问题，通常不识别这种情况就无法解决这类问题。例如，如果物理电话簿按姓的字母顺序排序，而城市里所有人的姓都是 Smith 或 Jones，则无法快速找到某个人。