大多數(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ù)的訪問(wèn)速度。 1. 索引的體系結(jié)構(gòu) SQL Server 2005在硬盤(pán)中用8KB頁(yè)面在數(shù)據(jù)庫(kù)文件內(nèi)存放數(shù)據(jù)。缺省情況下這些頁(yè)面及其包含的數(shù)據(jù)是無(wú)組織的。為了使混亂變?yōu)橛行?,就要生成索引。生成索引后,就有了索引?yè)和數(shù)據(jù)頁(yè)之分:數(shù)據(jù)頁(yè)用來(lái)保存用戶寫(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è)1/2滿頁(yè)。這樣就有大量的空的數(shù)據(jù)空間。簇索引是雙向鏈表,在每一頁(yè)的頭部保存了前一頁(yè)、后一頁(yè)以及分頁(yè)后數(shù)據(jù)移出的地址。由于新頁(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)
復(fù)制代碼輸出結(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. 復(fù)制代碼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ū)域改變,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è)索引。DBCC DBREINDEX ( [ 'database.owner.table_name' [ , index_name [ , fillfactor ] ] ] )
復(fù)制代碼參數(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)橐阎亟ň奂饕┑男履J(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. 復(fù)制代碼通過(guò)結(jié)果我們可以看到Scan Denity為100%。 原文出自【比特網(wǎng)】,轉(zhuǎn)載請(qǐng)保留原文鏈接:http://bbs./thread-366635-1-1.html |
|
來(lái)自: Jason(徐子) > 《Sql server》