优化SQL Server索引的小技巧

SQLServer中有几个可以让你检测、调整和优化SQL Server性能的工具。在本文中，我将说明如何用SQL Server的工具来优化数据库索引的使用，本文还涉及到有关索引的一般性知识。

关于索引的常识

影响到数据库性能的最大因素就是索引。由于该问题的复杂性，我只可能简单的谈谈这个问题，不过关于这方面的问题，目前有好几本不错的书籍可供你参阅。我在这里只讨论两种SQLServer索引，即clustered索引和nonclustered索引。当考察建立什么类型的索引时，你应当考虑数据类型和保存这些数据的column。同样，你也必须考虑数据库可能用到的查询类型以及使用的最为频繁的查询类型。

索引的类型

如果column保存了高度相关的数据，并且常常被顺序访问时，最好使用clustered索引，这是因为如果使用clustered索引，SQLServer会在物理上按升序（默认）或者降序重排数据列，这样就可以迅速的找到被查询的数据。同样，在搜寻控制在一定范围内的情况下，对这些column也最好使用clustered索引。这是因为由于物理上重排数据，每个表格上只有一个clustered索引。


与上面情况相反，如果columns包含的数据相关性较差，你可以使用nonculstered索引。你可以在一个表格中使用高达249个nonclustered索引——尽管我想象不出实际应用场合会用的上这么多索引。

当表格使用主关键字（primary keys），默认情况下SQL Server会自动对包含该关键字的column(s)建立一个独有的cluster索引。很显然，对这些column(s)建立独有索引意味着主关键字的唯一性。当建立外关键字（foreignkey）关系时，如果你打算频繁使用它，那么在外关键字cloumn上建立nonclustered索引不失为一个好的方法。如果表格有clustered索引，那么它用一个链表来维护数据页之间的关系。相反，如果表格没有clustered索引，SQLServer将在一个堆栈中保存数据页。

数据页

当索引建立起来的时候，SQLServer就建立数据页（datapage），数据页是用以加速搜索的指针。当索引建立起来的时候，其对应的填充因子也即被设置。设置填充因子的目的是为了指示该索引中数据页的百分比。随着时间的推移，数据库的更新会消耗掉已有的空闲空间，这就会导致页被拆分。页拆分的后果是降低了索引的性能，因而使用该索引的查询会导致数据存储的支离破碎。当建立一个索引时，该索引的填充因子即被设置好了，因此填充因子不能动态维护。

为了更新数据页中的填充因子，我们可以停止旧有索引并重建索引，并重新设置填充因子（注意：这将影响到当前数据库的运行，在重要场合请谨慎使用）。
DBCC INDEXDEFRAG和DBCCDBREINDEX是清除clustered和nonculstered索引碎片的两个命令。INDEXDEFRAG是一种在线操作（也就是说，它不会阻塞其它表格动作，如查询），而DBREINDEX则在物理上重建索引。在绝大多数情况下，重建索引可以更好的消除碎片，但是这个优点是以阻塞当前发生在该索引所在表格上其它动作为代价换取来得。当出现较大的碎片索引时，INDEXDEFRAG会花上一段比较长的时间，这是因为该命令的运行是基于小的交互块（transactionalblock）。

填充因子

当你执行上述措施中的任何一个，数据库引擎可以更有效的返回编入索引的数据。关于填充因子（fillfactor）话题已经超出了本文的范畴，不过我还是提醒你需要注意那些打算使用填充因子建立索引的表格。

在执行查询时，SQL Server动态选择使用哪个索引。为此，SQLServer根据每个索引上分布在该关键字上的统计量来决定使用哪个索引。值得注意的是，经过日常的数据库活动（如插入、删除和更新表格），SQLServer用到的这些统计量可能已经“过期”了，需要更新。你可以通过执行DBCCSHOWCONTIG来查看统计量的状态。当你认为统计量已经“过期”时，你可以执行该表格的UPDATE STATISTICS命令，这样SQLServer就刷新了关于该索引的信息了。

建立数据库维护计划

SQL Server提供了一种简化并自动维护数据库的工具。这个称之为数据库维护计划向导（Database MaintenancePlan Wizard，DMPW）的工具也包括了对索引的优化。如果你运行这个向导，你会看到关于数据库中关于索引的统计量，这些统计量作为日志工作并定时更新，这样就减轻了手工重建索引所带来的工作量。如果你不想自动定期刷新索引统计量，你还可以在DMPW中选择重新组织数据和数据页，这将停止旧有索引并按特定的填充因子重建索引。

SQL Server数据库中，当索引碎片太多时，就会拖慢数据库查询的速度。这时我们可以通过整理索引碎片和重建索引来解决，本文我们主要就介绍了这部分内容，希望能够对您有所帮助。

AD：

SQL Server数据库操作中，当数据库中的记录比较多的时候，我们可以通过索引来实现查询。但是当索引碎片太多的时候，就会很严重地影响到查询的速度。这时候我们可以采取两种方法来解决：一种时整理索引碎片，另一种是重建索引。本文主要介绍了这一过程，接下来就让我们来一起了解一下吧。

检查索引碎片DBCC SHOWCONTIG(表)，得到如下结果：

   
   
DBCC SHOWCONTIG 正在扫描 'A' 表...  
 
表: 'A'（884198200）；索引 ID: 1，数据库 ID: 13  
 
已执行 TABLE 级别的扫描。  
 
- 扫描页数.....................................: 3127  
 
- 扫描扩展盘区数...............................: 403  
 
- 扩展盘区开关数...............................: 1615  
 
- 每个扩展盘区上的平均页数.....................: 7.8  
 
- 扫描密度［最佳值:实际值］....................: 24.20%［391:1616］  
 
- 逻辑扫描碎片.................................: 68.02%  
 
- 扩展盘区扫描碎片.............................: 38.46%  
 
- 每页上的平均可用字节数.......................: 2073.2  
 
- 平均页密度（完整）...........................: 74.39%  
 
DBCC 执行完毕。 

由上我们看出，逻辑扫描碎片和扩展盘区扫描碎片都非常大，果然需要对索引碎片进行处理了。

一般有两种方法解决，一是利用DBCC INDEXDEFRAG整理索引碎片，二是利用DBCC DBREINDEX重建索引。二者各有优缺点。调用微软的原话如下：

DBCC INDEXDEFRAG 命令是联机操作，所以索引只有在该命令正在运行时才可用。而且可以在不丢失已完成工作的情况下中断该操作。这种方法的缺点是在重新组织数据方面没有聚集索引的除去/重新创建操作有效。

重新创建聚集索引将对数据进行重新组织，其结果是使数据页填满。填满程度可以使用 FILLFACTOR 选项进行配置。这种方法的缺点是索引在除去/重新创建周期内为脱机状态，并且操作属原子级。如果中断索引创建，则不会重新创建该索引。

也就是说，要想获得好的效果，还是得用重建索引，所以决定重建索引。

DBCC DBREINDEX(表，索引名，填充因子）

第一个参数，可以是表名，也可以是表ID。

第二个参数，如果是''，表示影响该表的所有索引。

第三个参数，填充因子，即索引页的数据填充程度。如果是100，表示每一个索引页都全部填满，此时select效率最高，但以后要插入索引时，就得移动后面的所有页，效率很低。如果是0，表示使用先前的填充因子值。

DBCC DBREINDEX(A，''，100)

重新测试速度，发现速度已经非常快了。

关于SQL Server数据库通过整理索引碎片和重建索引来提高索引速度的知识就介绍到这里了，希望本次的介绍能够对您有所收获。

 

SQL Server数据库中通过使用DBCC ShowContig来检查索引碎片情况，然后定期地对索引进行重建，可以大大地优化数据库的性能，本文主要介绍了DBCC ShowContig的使用方法，希望能够对您有所帮助。

AD：

在SQL Server数据库，当索引碎片较多时，会拖慢查询的速度，进而影响SQL查询的性能，这时可以通过DBCC ShowContig或DBCC ShowContig(表名)检查索引碎片情况，指导我们对其进行定时重建整理。本文我们就介绍这一过程，接下来我们就来一起了解一下吧。

执行DBCC ShowContig后的运行结果如下：

   
   
DBCC SHOWCONTIG 正在扫描 'tbModule' 表...   
 
表: 'tbModule'（1845581613）；索引 ID: 0，数据库 ID: 9   
 
已执行 TABLE 级别的扫描。   
 
扫描页数.....................................: 51  
 
扫描扩展盘区数...............................: 9   
 
扩展盘区开关数...............................: 8   
 
每个扩展盘区上的平均页数.....................: 5.7   
 
扫描密度［最佳值:实际值］....................: 77.78%［7:9］   
 
扩展盘区扫描碎片.............................: 77.78%   
 
每页上的平均可用字节数.......................: 351.1   
 
平均页密度（完整）...........................: 95.66% 

相关解释如下：

Page Scanned-扫描页数：如果你知道行的近似尺寸和表或索引里的行数，那么你可以估计出索引里的页数。看看扫描页数，如果明显比你估计的页数要高，说明存在内部碎片。

Extents Scanned-扫描扩展盘区数：用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高，说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。

Extent Switches-扩展盘区开关数：该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。

Avg. Pages per Extent-每个扩展盘区上的平均页数：该数是扫描页数除以扫描扩展盘区数，一般是8。小于8说明有外部碎片。

Scan Density [Best Count:Actual Count]-扫描密度［最佳值:实际值］：DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100％。低了则说明有外部碎片。

Logical Scan Fragmentation-逻辑扫描碎片：无序页的百分比。该百分比应该在0％到10％之间，高了则说明有外部碎片。

Extent Scan Fragmentation-扩展盘区扫描碎片：无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0％，高了则说明有外部碎片。

Avg. Bytes Free per Page-每页上的平均可用字节数：所扫描的页上的平均可用字节数。越高说明有内部碎片，不过在你用这个数字决定是否有内部碎片之前，应该考虑fill factor（填充因子）。

Avg. Page Density (full)-平均页密度（完整）：每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。

通过对扫描密度（过低），扫描碎片（过高）的结果分析，判定是否需要索引重建。

处理方式：一是利用DBCC INDEXDEFRAG整理索引碎片，二是利用DBCC DBREINDEX重建索引。二者各有优缺点。

调用微软的原话如下：

DBCC INDEXDEFRAG 命令是联机操作，所以索引只有在该命令正在运行时才可用，而且可以在不丢失已完成工作的情况下中断该操作。这种方法的缺点是在重新组织数据方面没有聚集索引的除去/重新创建操作有效。

重新创建聚集索引将对数据进行重新组织，其结果是使数据页填满。填满程度可以使用 FILLFACTOR 选项进行配置。这种方法的缺点是索引在除去/重新创建周期内为脱机状态，并且操作属原子级。如果中断索引创建，则不会重新创建该索引。也就是说，要想获得好的效果，还是得用重建索引，所以决定重建索引。

DBCC DBREINDEX(表，索引名，填充因子）

第一个参数，可以是表名，也可以是表ID。

第二个参数，如果是''，表示影响该表的所有索引。

第三个参数，填充因子，即索引页的数据填充程度。如果是100，表示每一个索引页都全部填满，此时select效率最高，但以后要插入索引时，就得移动后面的所有页，效率很低。如果是0，表示使用先前的填充因子值。

如对表tbModule的所有索引进行重建，填充因子比例为80% ，可以这么写：DBCC DBREINDEX（tbModule,'',80)。