DBCC DBREINDEX重建索引提高SQL Server性能
大多數SQL Server表需要索引來提高數據的訪問速度，如果沒有索引，SQL Server 要進行表格掃描讀取表中的每一個記錄才能找到索要的數據。索引可以分為簇索引和非簇索引，簇索引通過重排表中的數據來提高數據的訪問速度，而非簇索引則通過維護表中的數據指針來提高數據的索引。
1. 索引的體系結構
為什麽要不斷的維護表的索引？首先，簡單介紹一下索引的體系結構。SQL Server在硬盤中用8KB頁面在數據庫文件內存放數據。缺省情況下這些頁面及其包含的數據是無組織的。為了使混亂變為有序，就要生成索引。生成索引後，就有了索引頁和數據頁，數據頁保存用戶寫入的數據信息。索引頁存放用於檢索列的數據值清單（關鍵字）和索引表中該值所在紀錄的地址指針。索引分為簇索引和非簇索引，簇索引實質上是將表中的數據排序，就好像是字典的索引目錄。非簇索引不對數據排序，它只保存了數據的指針地址。向一個帶簇索引的表中插入數據，當數據頁達到100%時，由於頁面沒有空間插入新的的紀錄，這時就會發生分頁，SQL Server 將大約一半的數據從滿頁中移到空頁中，從而生成兩個半的滿頁。這樣就有大量的數據空間。簇索引是雙向鏈表，在每一頁的頭部保存了前一頁、後一頁地址以及分頁後數據移動的地址，由於新頁可能在數據庫文件中的任何地方，因此頁面的鏈接不一定指向磁盤的下一個物理頁，鏈接可能指向了另一個區域，這就形成了分塊，從而減慢了系統的速度。對於帶簇索引和非簇索引的表來說，非簇索引的關鍵字是指向簇索引的，而不是指向數據頁的本身。
為了克服數據分塊帶來的負面影響，需要重構表的索引，這是非常費時的，因此只能在需要時進行。可以通過DBCC SHOWCONTIG來確定是否需要重構表的索引。
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 在創建索引時將使用指定的起始 fillfactor。
同樣在Query Analyzer中輸入命令：
dbcc dbreindex(‘database_name.dbo.Employee‘,‘‘,90)
然後再用DBCC SHOWCONTIG查看重構索引後的結果：
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的性能》
http://www.csdn.com.cn/database/1142.htm
作者：unknown
數據庫表A有十萬條記錄，查詢速度本來還可以，但導入一千條數據後，問題出現了。當選擇的數據在原十萬條記錄之間時，速度還是挺快的；但當選擇的數據在這一千條數據之間時，速度變得奇慢。
憑經驗，這是索引碎片問題。檢查索引碎片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 輸出了錯誤信息，請與系統管理員聯系。
由上我們看出，邏輯掃描碎片和擴展盤區掃描碎片都非常大，果真需要對索引碎片進行處理了。
一般有兩種方法解決，一是利用DBCC INDEXDEFRAG整理索引碎片，二是利用DBCC DBREINDEX重建索引。二者各有優缺點。調用微軟的原話如下：
DBCC INDEXDEFRAG 命令是聯機操作，所以索引只有在該命令正在運行時才可用。而且可以在不丟失已完成工作的情況下中斷該操作。這種方法的缺點是在重新組織數據方面沒有聚集索引的除去/重新創建操作有效。
重新創建聚集索引將對數據進行重新組織，其結果是使數據頁填滿。填滿程度可以使用 FILLFACTOR 選項進行配置。這種方法的缺點是索引在除去/重新創建周期內為脫機狀態，並且操作屬原子級。如果中斷索引創建，則不會重新創建該索引。
也就是說，要想獲得好的效果，還是得用重建索引，所以決定重建索引。
DBCC DBREINDEX(表，索引名，填充因子）
第一個參數，可以是表名，也可以是表ID。
第二個參數，如果是‘‘，表示影響該表的所有索引。
第三個參數，填充因子，即索引頁的數據填充程度。如果是100，表示每一個索引頁都全部填滿，此時select效率最高，但以後要插入索引時，就得移動後面的所有頁，效率很低。如果是0，表示使用先前的填充因子值。
DBCC DBREINDEX(A，‘‘，100)
重新測試查詢速度，飛快。
DBCC SHOWCONTIG是顯示指定的表的數據和索引的碎片信息。
解釋如下：
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 DBREINDEX重建索引提高SQL Server性能