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%。

總結

以上是生活随笔為你收集整理的dbcc dbreindex server sql_DBCC DBREINDEX重建索引提高SQL Server性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。