大多數(shù)SQL

Server表需要索引來提高數(shù)據(jù)的訪問速度，如果沒有索引，SQL Server

要進(jìn)行表格掃描讀取表中的每一個(gè)記錄才能找到索要的數(shù)據(jù)。索引可以分為簇索引和非簇索引，簇索引通過重排表中的數(shù)據(jù)來提高數(shù)據(jù)的訪問速度，而非簇索引則通過維護(hù)表中的數(shù)據(jù)指針來提高數(shù)據(jù)的索引。

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

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

Server在硬盤中用8KB頁面在數(shù)據(jù)庫文件內(nèi)存放數(shù)據(jù)。缺省情況下這些頁面及其包含的數(shù)據(jù)是無組織的。為了使混亂變?yōu)橛行?#xff0c;就要生成索引。生成索引后，就有了索引頁和數(shù)據(jù)頁，數(shù)據(jù)頁保存用戶寫入的數(shù)據(jù)信息。索引頁存放用于檢索列的數(shù)據(jù)值清單(關(guān)鍵字)和索引表中該值所在紀(jì)錄的地址指針。索引分為簇索引和非簇索引，簇索引實(shí)質(zhì)上是將表中的數(shù)據(jù)排序，就好像是字典的索引目錄。非簇索引不對(duì)數(shù)據(jù)排序，它只保存了數(shù)據(jù)的指針地址。向一個(gè)帶簇索引的表中插入數(shù)據(jù)，當(dāng)數(shù)據(jù)頁達(dá)到100%時(shí)，由于頁面沒有空間插入新的的紀(jì)錄，這時(shí)就會(huì)發(fā)生分頁，SQL

Server

將大約一半的數(shù)據(jù)從滿頁中移到空頁中，從而生成兩個(gè)半的滿頁。這樣就有大量的數(shù)據(jù)空間。簇索引是雙向鏈表，在每一頁的頭部保存了前一頁、后一頁地址以及分頁后數(shù)據(jù)移動(dòng)的地址，由于新頁可能在數(shù)據(jù)庫文件中的任何地方，因此頁面的鏈接不一定指向磁盤的下一個(gè)物理頁，鏈接可能指向了另一個(gè)區(qū)域，這就形成了分塊，從而減慢了系統(tǒng)的速度。對(duì)于帶簇索引和非簇索引的表來說，非簇索引的關(guān)鍵字是指向簇索引的，而不是指向數(shù)據(jù)頁的本身。

為了克服數(shù)據(jù)分塊帶來的負(fù)面影響，需要重構(gòu)表的索引，這是非常費(fèi)時(shí)的，因此只能在需要時(shí)進(jìn)行。可以通過DBCC

SHOWCONTIG來確定是否需要重構(gòu)表的索引。

2. DBCC

SHOWCONTIG用法

下面舉例來說明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.

通過分析這些結(jié)果可以知道該表的索引是否需要重構(gòu)。如下描述了每一行的意義：

信息?描述

Pages

Scanned?表或索引中的長(zhǎng)頁數(shù)

Extents

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

Extent

Switches?DBCC遍歷頁時(shí)從一個(gè)區(qū)域到另一個(gè)區(qū)域的次數(shù)

Avg. Pages per

Extent?相關(guān)區(qū)域中的頁數(shù)

Scan Density[Best Count:Actual

Count]

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

Density為100%表示沒有分塊。

Logical Scan

Fragmentation?掃描索引頁中失序頁的百分比

Extent Scan

Fragmentation?不實(shí)際相鄰和包含鏈路中所有鏈接頁的區(qū)域數(shù)

Avg. Bytes Free per

Page?掃描頁面中平均自由字節(jié)數(shù)

Avg. Page Density

(full)?平均頁密度，表示頁有多滿

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

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

總結(jié)

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

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