| 以文本方式查看主題 - 昂捷論壇 (http://www.yzsenyi.com/bbs/index.asp) -- □-技術(shù)研討會(huì) (http://www.yzsenyi.com/bbs/list.asp?boardid=36) ---- SQLServer索引碎片和解決方法 (http://www.yzsenyi.com/bbs/dispbbs.asp?boardid=36&id=9035) |
||
| -- 作者：飛絮 -- 發(fā)布時(shí)間：2013/11/7 15:22:13 -- SQLServer索引碎片和解決方法 毫無(wú)疑問(wèn)，給表添加索引是有好處的，你要做的大部分工作就是維護(hù)索引，在數(shù)據(jù)更改期間索引可能產(chǎn)生碎片，所以一些維護(hù)是必要的。碎片可能是你查詢產(chǎn)生性能問(wèn)題的來(lái)源。 那么到底什么是索引碎片呢？索引碎片實(shí)際上有2種形式：外部碎片和內(nèi)部碎片。不管哪種碎片基本上都會(huì)影響索引內(nèi)頁(yè)的使用。這也許是因?yàn)轫?yè)的邏輯順序錯(cuò)誤（即外部碎片）或每頁(yè)存儲(chǔ)的數(shù)據(jù)量少于數(shù)據(jù)頁(yè)的容量（內(nèi)部錯(cuò)誤）。無(wú)論索引產(chǎn)生了哪種類型的碎片，你都會(huì)因?yàn)樗媾R查詢的性能問(wèn)題。 外部碎片 當(dāng)索引頁(yè)不在邏輯順序上時(shí)就會(huì)產(chǎn)生外部碎片。索引創(chuàng)建時(shí)，索引鍵按照邏輯順序放在一組索引頁(yè)上。當(dāng)新數(shù)據(jù)插入索引時(shí)，新的鍵可能放在存在的鍵之間。為了讓新的鍵按照正確的順序插入，可能會(huì)創(chuàng)建新的索引頁(yè)來(lái)存儲(chǔ)需要移動(dòng)的那些存在的鍵。這些新的索引頁(yè)通常物理上不會(huì)和那些被移動(dòng)的鍵原來(lái)所在的頁(yè)相鄰。創(chuàng)建新頁(yè)的過(guò)程會(huì)引起索引頁(yè)偏離邏輯順序。 下面的例子將比實(shí)際的言論更加清晰的解釋這個(gè)概念。 假定在任何另外的數(shù)據(jù)插入你的表之前存在索引上的結(jié)構(gòu)如下 。ㄗⅲ合旅鎴D片里應(yīng)該是7和8，原文里是6和8）： INSERT語(yǔ)句往索引里添加新的數(shù)據(jù)，假定添加的是5。INSERT將引起新頁(yè)創(chuàng)建，為了給5在原來(lái)的頁(yè)上留出空間，7和8被移到了新頁(yè)上。這個(gè)創(chuàng)建將引起索引頁(yè)偏離邏輯順序。 在有特定搜索或者返回?zé)o序結(jié)果集的查詢的情況下，偏離順序的索引頁(yè)不會(huì)引起問(wèn)題。對(duì)于返回有序結(jié)果集的查詢，搜索那些無(wú)序的索引頁(yè)需要進(jìn)行額外的處理。有序結(jié)果集的例子如查詢返回4到10之間的記錄。為了返回7和8，查詢不得不進(jìn)行額外的頁(yè)切換。雖然一個(gè)額外的頁(yè)切換在一個(gè)長(zhǎng)時(shí)間運(yùn)行里是無(wú)關(guān)緊要的，然而想象一下一個(gè)有好幾百頁(yè)偏離順序的非常大的表的情形。 內(nèi)部碎片 當(dāng)索引頁(yè)沒(méi)有用到最大量時(shí)就產(chǎn)生了內(nèi)部碎片。雖然在一個(gè)有頻繁數(shù)據(jù)插入的應(yīng)用程序里這也許有幫助，然而設(shè)置一個(gè)fill factor（填充因子）會(huì)在索引頁(yè)上留下空間，服務(wù)器內(nèi)部碎片會(huì)導(dǎo)致索引尺寸增加，從而在返回需要的數(shù)據(jù)時(shí)要執(zhí)行額外的讀操作。這些額外的讀操作會(huì)降低查詢的性能。 怎樣確定索引是否有碎片？ SQLServer提供了一個(gè)數(shù)據(jù)庫(kù)命令――DBCC SHOWCONTIG――來(lái)確定一個(gè)指定的表或索引是否有碎片。 DBCC SHOWCONTIG 數(shù)據(jù)庫(kù)平臺(tái)命令，用來(lái)顯示指定的表的數(shù)據(jù)和索引的碎片信息。 DBCC SHOWCONTIG 權(quán)限默認(rèn)授予 sysadmin固定服務(wù)器角色或 db_owner 和 db_ddladmin固定數(shù)據(jù)庫(kù)角色的成員以及表的所有者且不可轉(zhuǎn)讓。 語(yǔ)法（SQLServer2000） DBCC SHOWCONTIG [ ( { table_name | table_id| view_name | view_id } [ , index_name | index_id ] ) ] [ WITH { ALL_INDEXES | FAST [ , ALL_INDEXES ] | TABLERESULTS [ , { ALL_INDEXES } ] [ , { FAST | ALL_LEVELS } ] } ] 語(yǔ)法（SQLServer7.0） DBCC SHOWCONTIG [ ( table_id [,index_id ] ) ] 示例： 顯示數(shù)據(jù)庫(kù)里所有索引的碎片信息 SET NOCOUNT ON USE pubs DBCC SHOWCONTIG WITH ALL_INDEXES GO 顯示指定表的所有索引的碎片信息 SET NOCOUNT ONUSE pubs DBCC SHOWCONTIG (authors) WITH ALL_INDEXES GO 顯示指定索引的碎片信息 SET NOCOUNT ON USE pubs DBCC SHOWCONTIG (authors,aunmind) GO DBCC SHOWCONTIG (\'表名\') 結(jié)果集 DBCC SHOWCONTIG將返回掃描頁(yè)數(shù)、掃描擴(kuò)展盤(pán)區(qū)數(shù)、遍歷索引或表的頁(yè)時(shí)，DBCC 語(yǔ)句從一個(gè)擴(kuò)展盤(pán)區(qū)移動(dòng)到其它擴(kuò)展盤(pán)區(qū)的次數(shù)、每個(gè)擴(kuò)展盤(pán)區(qū)的頁(yè)數(shù)、掃描密度（最佳值是指在一切都連續(xù)地鏈接的情況下，擴(kuò)展盤(pán)區(qū)更改的理想數(shù)目）。 DBCC SHOWCONTIG 正在掃描 \'authors\' 表... 表: \'authors\'（1977058079）； 索引 ID: 1，數(shù)據(jù)庫(kù) ID: 5 已執(zhí)行 TABLE 級(jí)別的掃描。 - 掃描頁(yè)數(shù).....................................: 1 - 掃描擴(kuò)展盤(pán)區(qū)數(shù)...............................: 1 - 擴(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)...............................: 0 - 每個(gè)擴(kuò)展盤(pán)區(qū)上的平均頁(yè)數(shù).....................: 1.0 - 掃描密度［最佳值:實(shí)際值］....................: 100.00%［1:1］ - 邏輯掃描碎片.................................: 0.00% - 擴(kuò)展盤(pán)區(qū)掃描碎片.............................: 0.00% - 每頁(yè)上的平均可用字節(jié)數(shù).......................: 6010.0 - 平均頁(yè)密度（完整）...........................: 25.75% DBCC 執(zhí)行完畢。如果 DBCC 輸出了錯(cuò)誤信息，請(qǐng)與系統(tǒng)管理員聯(lián)系。 掃描頁(yè)數(shù)：如果你知道行的近似尺寸和表或索引里的行數(shù)，那么你可以估計(jì)出索引里的頁(yè)數(shù)？纯磼呙桧(yè)數(shù)，如果明顯比你估計(jì)的頁(yè)數(shù)要高，說(shuō)明存在內(nèi)部碎片。 掃描擴(kuò)展盤(pán)區(qū)數(shù)：用掃描頁(yè)數(shù)除以8,四舍五入到下一個(gè)最高值。該值應(yīng)該和DBCC SHOWCONTIG返回的掃描擴(kuò)展盤(pán)區(qū)數(shù)一致。如果DBCC SHOWCONTIG返回的數(shù)高，說(shuō)明存在外部碎片。碎片的嚴(yán)重程度依賴于剛才顯示的值比估計(jì)值高多少。 擴(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)：該數(shù)應(yīng)該等于掃描擴(kuò)展盤(pán)區(qū)數(shù)減1。高了則說(shuō)明有外部碎片。 每個(gè)擴(kuò)展盤(pán)區(qū)上的平均頁(yè)數(shù)：該數(shù)是掃描頁(yè)數(shù)除以掃描擴(kuò)展盤(pán)區(qū)數(shù)，一般是8。小于8說(shuō)明有外部碎片。 掃描密度［最佳值:實(shí)際值］：DBCC SHOWCONTIG返回最有用的一個(gè)百分比。這是擴(kuò)展盤(pán)區(qū)的最佳值和實(shí)際值的比率。該百分比應(yīng)該盡可能靠近100％。低了則說(shuō)明有外部碎片。 邏輯掃描碎片：無(wú)序頁(yè)的百分比。該百分比應(yīng)該在0％到10％之間，高了則說(shuō)明有外部碎片。 擴(kuò)展盤(pán)區(qū)掃描碎片：無(wú)序擴(kuò)展盤(pán)區(qū)在掃描索引葉級(jí)頁(yè)中所占的百分比。該百分比應(yīng)該是0％，高了則說(shuō)明有外部碎片。 每頁(yè)上的平均可用字節(jié)數(shù)：所掃描的頁(yè)上的平均可用字節(jié)數(shù)。越高說(shuō)明有內(nèi)部碎片，不過(guò)在你用這個(gè)數(shù)字決定是否有內(nèi)部碎片之前，應(yīng)該考慮fill factor（填充因子）。 平均頁(yè)密度（完整）：每頁(yè)上的平均可用字節(jié)數(shù)的百分比的相反數(shù)。低的百分比說(shuō)明有內(nèi)部碎片。 備注 DBCC SHOWCONTIG實(shí)際上僅對(duì)那些大表有用。小表顯示的結(jié)果根本不符合正常標(biāo)準(zhǔn)，因?yàn)樗麄円苍S沒(méi)有由多于8個(gè)的頁(yè)面組成。你在查看小表上執(zhí)行DBCC SHOWCONTIG的結(jié)果時(shí)應(yīng)該忽略一些結(jié)果。在處理小表時(shí)只需關(guān)心擴(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)、邏輯掃描碎片、每頁(yè)上的平均可用字節(jié)數(shù)、平均頁(yè)密度（完整）。 DBCC SHOWCONTIG默認(rèn)輸出的結(jié)果是：掃描頁(yè)數(shù)、掃描擴(kuò)展盤(pán)區(qū)數(shù)、擴(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)、每個(gè)擴(kuò)展盤(pán)區(qū)上的平均頁(yè)數(shù)、掃描密度［最佳值:實(shí)際值］、邏輯掃描碎片、擴(kuò)展盤(pán)區(qū)掃描碎片、每頁(yè)上的平均可用字節(jié)數(shù)、平均頁(yè)密度（完整）？梢杂肍AST和TABLERESULTS選項(xiàng)來(lái)控制這個(gè)輸出結(jié)果。 FAST選項(xiàng)指定執(zhí)行索引的快速掃描，輸出結(jié)果是最小的，該選項(xiàng)不讀索引的葉或數(shù)據(jù)頁(yè)且只返回掃描頁(yè)數(shù)、掃描擴(kuò)展盤(pán)區(qū)數(shù)、掃描密度［最佳值:實(shí)際值］、邏輯掃描碎片。 TABLERESULTS選項(xiàng)將用行集的形式顯示信息，將返回?cái)U(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)、掃描密度［最佳值:實(shí)際值］、邏輯掃描碎片、擴(kuò)展盤(pán)區(qū)掃描碎片、每頁(yè)上的平均可用字節(jié)數(shù)、平均頁(yè)密度（完整）。 如果既指定FAST選項(xiàng)又指定TABLERESULTS選項(xiàng)，那么將返回對(duì)象名、對(duì)象ID、索引名、索引ID，頁(yè)數(shù)、擴(kuò)展盤(pán)區(qū)開(kāi)關(guān)數(shù)、掃描密度［最佳值:實(shí)際值］和邏輯掃描碎片。 ALL_INDEXES選項(xiàng)將顯示指定表和試圖的所有索引的結(jié)果，即使指定了一個(gè)索引。 ALL_LEVELS選項(xiàng)指定是否為所處理的每個(gè)索引的每個(gè)級(jí)別產(chǎn)生輸出（默認(rèn)只輸出索引的頁(yè)級(jí)或表數(shù)據(jù)級(jí)的結(jié)果），并且只能與 TABLERESULTS 選項(xiàng)一起使用。 解決碎片問(wèn)題 一旦你確定表或索引有碎片問(wèn)題，那么你有4個(gè)選擇去解決那些問(wèn)題： 刪除并重建索引 使用DROP_EXISTING子句重建索引 執(zhí)行DBCC DBREINDEX 執(zhí)行DBCC INDEXDEFRAG 盡管每一個(gè)技術(shù)都能達(dá)到你整理索引碎片的最終目的，但各有各的優(yōu)缺點(diǎn)。 刪除并重建索引 用DROP INDEX和CREATE INDEX或ALTER TABLE來(lái)刪除并重建索引有些缺陷包括在刪除重建期間索引會(huì)消失。在索引刪除重建時(shí)，對(duì)于查詢它不在可用，查詢性能也許會(huì)受到明顯的影響，直到重建索引為止。另一個(gè)潛在的缺陷是當(dāng)都請(qǐng)求索引的時(shí)候會(huì)引起阻塞，直到重建索引為止。通過(guò)其他的處理也能解決阻塞，就是索引被使用的時(shí)候不刪除索引。另一個(gè)主要的缺陷是在用DROP INDEX和CREATE INDEX重建聚集索引時(shí)會(huì)引起非聚集索引重建兩次。刪除聚集索引時(shí)非聚集索引的行指針會(huì)指向數(shù)據(jù)堆，聚集索引重建時(shí)非聚集索引的行指針又會(huì)指回聚集索引的行位置。 刪除并重建索引的確有一個(gè)好處就是通過(guò)重新排序索引頁(yè)，使索引頁(yè)緊湊并刪除不需要的索引頁(yè)來(lái)完全重建索引。你也許需要考慮那些內(nèi)部和外部碎片都很高的情況下才使用，以使那些索引回到它們應(yīng)該在的位置。 使用DROP_EXISTING子句重建索引 為了避免在重建聚集索引時(shí)表上的非聚集索引重建兩次，可以使用帶DROP_EXISTING子句的CREATE INDEX語(yǔ)句。這個(gè)子句會(huì)保留聚集索引鍵值，以避免非聚集索引重建兩次。和刪除并重建索引一樣，該方法也可能會(huì)引起阻塞和索引消失的問(wèn)題。該方法的另一個(gè)缺陷是也強(qiáng)迫你去分別發(fā)現(xiàn)和修復(fù)表上的每一個(gè)索引。 除了和上一個(gè)方法一樣的好處之外，該方法的好處是不必重建非聚集索引兩次。這樣可以對(duì)那些帶約束的索引提供正確的索引定義以符合約束的要求。 執(zhí)行DBCC DBREINDEX DBCC DBREINDEX類似于第二種方法，但它物理地重建索引，允許SQLServer給索引分配新頁(yè)來(lái)減少內(nèi)部和外部碎片。DBCC DBREINDEX也能動(dòng)態(tài)的重建帶約束的索引，不象第二種方法。 DBCC DBREINDEX的缺陷是會(huì)遇到或引起阻塞問(wèn)題。DBCC DBREINDEX是作為一個(gè)事務(wù)來(lái)運(yùn)行的，所以如果在完成之前中斷了，那么你會(huì)丟失所有已經(jīng)執(zhí)行過(guò)的碎片。 執(zhí)行DBCC INDEXDEFRAG DBCC INDEXDEFRAG（在SQLServer2000中可用）按照索引鍵的邏輯順序，通過(guò)重新整理索引里存在的葉頁(yè)來(lái)減少外部碎片，通過(guò)壓縮索引頁(yè)里的行然后刪除那些由此產(chǎn)生的不需要的頁(yè)來(lái)減少內(nèi)部碎片。它不會(huì)遇到阻塞問(wèn)題但它的結(jié)果沒(méi)有其他幾個(gè)方法徹底。這是因?yàn)镈BCC INDEXDEFRAG跳過(guò)了鎖定的頁(yè)且不使用任何新頁(yè)來(lái)重新排序索引。如果索引的碎片數(shù)量大的話你也許會(huì)發(fā)現(xiàn)DBCC INDEXDEFRAG比重建索引花費(fèi)的時(shí)間更長(zhǎng)。DBCC INDEXDEFRAG比其他方法的確有好處的是在其他過(guò)程訪問(wèn)索引時(shí)也能進(jìn)行碎片整理，不會(huì)引起其他方法的阻塞問(wèn)題。 |