DBCC DBREINDEX重建索引提高SQL Server性能

[轉(zhuǎn)載]大多數(shù)SQL?Server表需要索引來(lái)提高數(shù)據(jù)的訪問(wèn)速度，如果沒(méi)有索引，SQL?Server

要進(jìn)行表格掃描讀取表中的每一個(gè)記錄才能找到索要的數(shù)據(jù)。索引可以分為簇索引和非簇索

引，簇索引通過(guò)重排表中的數(shù)據(jù)來(lái)提高數(shù)據(jù)的訪問(wèn)速度，而非簇索引則通過(guò)維護(hù)表中的數(shù)據(jù)

指針來(lái)提高數(shù)據(jù)的索引。

1.?索引的體系結(jié)構(gòu)

為什么要不斷的維護(hù)表的索引？首先，簡(jiǎn)單介紹一下索引的體系結(jié)構(gòu)。SQL

Server在硬盤(pán)中用8KB頁(yè)面在數(shù)據(jù)庫(kù)文件內(nèi)存放數(shù)據(jù)。缺省情況下這些頁(yè)面及其包含的數(shù)據(jù)

是無(wú)組織的。為了使混亂變?yōu)橛行?#xff0c;就要生成索引。生成索引后，就有了索引頁(yè)和數(shù)據(jù)頁(yè)，

數(shù)據(jù)頁(yè)保存用戶寫(xiě)入的數(shù)據(jù)信息。索引頁(yè)存放用于檢索列的數(shù)據(jù)值清單(關(guān)鍵字)和索引表

中該值所在紀(jì)錄的地址指針。索引分為簇索引和非簇索引，簇索引實(shí)質(zhì)上是將表中的數(shù)據(jù)排

序，就好像是字典的索引目錄。非簇索引不對(duì)數(shù)據(jù)排序，它只保存了數(shù)據(jù)的指針地址。向一

個(gè)帶簇索引的表中插入數(shù)據(jù)，當(dāng)數(shù)據(jù)頁(yè)達(dá)到100%時(shí)，由于頁(yè)面沒(méi)有空間插入新的的紀(jì)錄，這

時(shí)就會(huì)發(fā)生分頁(yè)，SQL?Server

將大約一半的數(shù)據(jù)從滿頁(yè)中移到空頁(yè)中，從而生成兩個(gè)半的滿頁(yè)。這樣就有大量的數(shù)據(jù)空間

。簇索引是雙向鏈表，在每一頁(yè)的頭部保存了前一頁(yè)、后一頁(yè)地址以及分頁(yè)后數(shù)據(jù)移動(dòng)的地

址，由于新頁(yè)可能在數(shù)據(jù)庫(kù)文件中的任何地方，因此頁(yè)面的鏈接不一定指向磁盤(pán)的下一個(gè)物

理頁(yè)，鏈接可能指向了另一個(gè)區(qū)域，這就形成了分塊，從而減慢了系統(tǒng)的速度。對(duì)于帶簇索

引和非簇索引的表來(lái)說(shuō)，非簇索引的關(guān)鍵字是指向簇索引的，而不是指向數(shù)據(jù)頁(yè)的本身。

為了克服數(shù)據(jù)分塊帶來(lái)的負(fù)面影響，需要重構(gòu)表的索引，這是非常費(fèi)時(shí)的，因此只能在需要

時(shí)進(jìn)行。可以通過(guò)DBCC?SHOWCONTIG來(lái)確定是否需要重構(gòu)表的索引。

2.?DBCC?SHOWCONTIG用法?下面舉例來(lái)說(shuō)明DBCC?SHOWCONTIG和DBCC

REDBINDEX的使用方法。以應(yīng)用程序中的Employee數(shù)據(jù)表作為例子，在?SQL?Server的Query

analyzer輸入命令：

use?database_name?declare?@table_id?int?set?@table_id=object_id(’Employee’)?dbcc?showcontig(@table_id)

輸出結(jié)果：

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.通過(guò)分析這些結(jié)果可以知道該表的索引是否需要重構(gòu)。如下描述了每一行的意義：?信息

描述?Pages?Scanned?表或索引中的長(zhǎng)頁(yè)數(shù)?Extents?Scanned

表或索引中的長(zhǎng)區(qū)頁(yè)數(shù)?Extent?Switches

DBCC遍歷頁(yè)時(shí)從一個(gè)區(qū)域到另一個(gè)區(qū)域的次數(shù)?Avg.?Pages?per?Extent

相關(guān)區(qū)域中的頁(yè)數(shù)?Scan?Density[Best?Count:Actual?Count]?Best

Count是連續(xù)鏈接時(shí)的理想?yún)^(qū)域改變數(shù)，Actual?Count是實(shí)際區(qū)域改變數(shù)，Scan

Density為100%表示沒(méi)有分塊。?Logical?Scan?Fragmentation

掃描索引頁(yè)中失序頁(yè)的百分比?Extent?Scan?Fragmentation

不實(shí)際相鄰和包含鏈路中所有鏈接頁(yè)的區(qū)域數(shù)?Avg.?Bytes?Free?per?Page

掃描頁(yè)面中平均自由字節(jié)數(shù)?Avg.?Page?Density?(full)

平均頁(yè)密度，表示頁(yè)有多滿

從上面命令的執(zhí)行結(jié)果可以看的出來(lái)，Best?count為23?而Actual

Count為25這表明orders表有分塊需要重構(gòu)表索引。下面通過(guò)DBCC

DBREINDEX來(lái)重構(gòu)表的簇索引。

3.?DBCC?DBREINDEX?用法?重建指定數(shù)據(jù)庫(kù)中表的一個(gè)或多個(gè)索引。

語(yǔ)法?DBCC?DBREINDEX?(?[?’database.owner.table_name’?[?,?index_name?[?,

fillfactor?]?]?]?)

參數(shù)?’database.owner.table_name’

是要重建其指定的索引的表名。數(shù)據(jù)庫(kù)、所有者和表名必須符合標(biāo)識(shí)符的規(guī)則。有關(guān)更多信

息，請(qǐng)參見(jiàn)使用標(biāo)識(shí)符。如果提供?database?或?owner?部分，則必須使用單引號(hào)?(’)

將整個(gè)?database.owner.table_name?括起來(lái)。如果只指定?table_name，則不需要單引號(hào)。

index_name?是要重建的索引名。索引名必須符合標(biāo)識(shí)符的規(guī)則。如果未指定?index_name

或指定為?’?’，就要對(duì)表的所有索引進(jìn)行重建。

fillfactor?是創(chuàng)建索引時(shí)每個(gè)索引頁(yè)上要用于存儲(chǔ)數(shù)據(jù)的空間百分比。fillfactor

替換起始填充因子以作為索引或任何其它重建的非聚集索引(因?yàn)橐阎亟ň奂饕?的新默

認(rèn)值。如果?fillfactor?為?0，DBCC?DBREINDEX?在創(chuàng)建索引時(shí)將使用指定的起始

fillfactor。

同樣在Query?Analyzer中輸入命令：

dbcc?dbreindex(’database_name.dbo.Employee’,’’,90)

然后再用DBCC?SHOWCONTIG查看重構(gòu)索引后的結(jié)果：

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.通過(guò)結(jié)果我們可以看到Scan?Denity為100%。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。