SQL Server性能的提高，可通過DBCC DBREINDEX重建索引
以下的文章主要介紹的是DBCC DBREINDEX重建索引對SQL Server性能進行提高的實際操作步驟，大多數SQL Server數據庫表需要索引來對數據的實際訪問速度進行提高，如果沒有索引，SQL Server要進行表格掃描讀取表中的每一個記錄才能找到索要的數據。
索引可以分為簇索引和非簇索
引，簇索引通過重排表中的數據來提高數據的訪問速度，而非簇索引提高SQL Server性能則通過維護表中的數據
指針來提高數據的索引。
1. 索引的體系結構
為什么要不斷的維護表的索引？首先，簡單介紹一下索引的體系結構。SQL
Server在硬盤中用8KB頁面在數據庫文件內存放數據。缺省情況下這些頁面及其包含的數據
是無組織的。為了使混亂變為有序，就要生成索引。生成索引后，就有了索引頁和數據頁，
數據頁保存用戶寫入的數據信息。索引頁存放用于檢索列的數據值清單（關鍵字）和索引表
中該值所在紀錄的地址指針。索引分為簇索引和非簇索引，簇索引實質上是將表中的數據排
序，就好像是字典的索引目錄。非簇索引不對數據排序，它只保存了數據的指針地址。向一
個帶簇索引提高SQL Server性能的表中插入數據，當數據頁達到100%時，由于頁面沒有空間插入新的的紀錄，這
時就會發生分頁，SQL Server
將大約一半的數據從滿頁中移到空頁中，從而生成兩個半的滿頁。這樣就有大量的數據空間
。簇索引是雙向鏈表，在每一頁的頭部保存了前一頁、后一頁地址以及分頁后數據移動的地
址，由于新頁可能在數據庫文件中的任何地方，因此頁面的鏈接不一定指向磁盤的下一個物
理頁，鏈接可能指向了另一個區域，這就形成了分塊，從而減慢了系統的速度。對于帶簇索
引和非簇索引的表來說，非簇索引的關鍵字是指向簇索引的，而不是指向數據頁的本身。
為了克服數據分塊帶來的負面影響，需要重構表的索引，這是非常費時的，因此只能在需要
時進行?？梢酝ㄟ^DBCC SHOWCONTIG來確定是否需要重構表的索引提高SQL Server性能。
2. DBCC SHOWCONTIG用法 下面舉例來說明DBCC SHOWCONTIG和DBCC
REDBINDEX的使用方法。以應用程序中的Employee數據表作為例子，在 SQL Server的Query
analyzer輸入命令：
use database_name declare @table_id int set @table_id=object_id(’Employee’) dbcc showcontig(@table_id)
輸出結果：
- DBCC SHOWCONTIG scanning ’Employee’ table... Table: ’Employee’
- (1195151303); index ID: 1, database ID: 53 TABLE level scan performed. - Pages
- Scanned................................: 179 - Extents
- Scanned..............................: 24 - Extent
- Switches..............................: 24 - Avg. Pages per
- Extent........................: 7.5 - Scan Density [Best Count:Actual
- Count].......: 92.00% [23:25] - Logical Scan Fragmentation ..................:
- 0.56% - Extent Scan Fragmentation ...................: 12.50% - Avg. Bytes Free
- per Page.....................: 552.3 - Avg. Page Density
- (full).....................: 93.18% DBCC execution completed. If DBCC printed
- error messages, contact your system administrator.
通過分析這些結果可以知道該表的索引是否需要重構。如下描述了每一行的意義： 信息
描述 Pages Scanned 表或索引中的長頁數 Extents Scanned
表或索引中的長區頁數 Extent Switches
DBCC遍歷頁時從一個區域到另一個區域的次數 Avg. Pages per Extent
相關區域中的頁數 Scan Density[Best Count:Actual Count] Best
Count是連續鏈接時的理想區域改變數，Actual Count是實際區域改變數，Scan
Density為100%表示沒有分塊。 Logical Scan Fragmentation
掃描索引頁中失序頁的百分比 Extent Scan Fragmentation
不實際相鄰和包含鏈路中所有鏈接頁的區域數 Avg. Bytes Free per Page
掃描頁面中平均自由字節數 Avg. Page Density (full)
平均頁密度，表示頁有多滿
從上面命令的執行結果可以看的出來，Best count為23 而Actual
Count為25這表明orders表有分塊需要重構表索引。下面通過DBCC
DBREINDEX來重構表的簇索引。
3. DBCC DBREINDEX 用法 重建指定數據庫中表的一個或多個索引。
語法 DBCC DBREINDEX ( [ ’database.owner.table_name’ [ , index_name [ ,
fillfactor ] ] ] )
參數 ’database.owner.table_name’
是要重建其指定的索引的表名。數據庫、所有者和表名必須符合標識符的規則。有關更多信
息，請參見使用標識符。如果提供 database 或 owner 部分，則必須使用單引號 (’)
將整個 database.owner.table_name 括起來。如果只指定 table_name，則不需要單引號。
index_name 是要重建的索引名。索引名必須符合標識符的規則。如果未指定 index_name
或指定為 ’ ’，就要對表的所有索引進行重建。
fillfactor 是創建索引時每個索引頁上要用于存儲數據的空間百分比。fillfactor
替換起始填充因子以作為索引或任何其它重建的非聚集索引（因為已重建聚集索引）的新默
認值。如果 fillfactor 為 0，DBCC DBREINDEX 在創建索引提高SQL Server性能時將使用指定的起始
fillfactor。
同樣在Query Analyzer中輸入命令：
- dbcc dbreindex(’database_name.dbo.Employee’,’’,90)
然后再用DBCC SHOWCONTIG查看重構索引提高SQL Server性能后的結果：
- DBCC SHOWCONTIG scanning
- ’Employee’ table... Table: ’Employee’ (1195151303); index ID: 1, database ID: 53
- TABLE level scan performed. - Pages Scanned................................: 178
- - Extents Scanned..............................: 23 - Extent
- Switches..............................: 22 - Avg. Pages per
- Extent........................: 7.7 - Scan Density [Best Count:Actual
- Count].......: 100.00% [23:23] - Logical Scan Fragmentation ..................:
- 0.00% - Extent Scan Fragmentation ...................: 0.00% - Avg. Bytes Free
- per Page.....................: 509.5 - Avg. Page Density
- (full).....................: 93.70% DBCC execution completed. If DBCC printed
- error messages, contact your system administrator.
通過結果我們可以看到Scan Denity為100%。
【編輯推薦】
- SQL Server刪除重復數據的2個實用方案
- 快速對SQL Server鎖機制進行掌握的竅門
- SQL Server存儲圖像數據大閱兵
- SQL Server重復數據刪除的2個操作方案
- SQL Server游標實例演示，不得不看！
