Pages & Extents（頁和擴展盤區）
??? SQL Server 2000最基本的數據存儲單元是data page，1個8K的存儲空間。在分配存儲空間時，SQL Server 2000并不是每次分配1個page，基本的存儲空間分配單元是8個page的連續空間，稱為extent。
??? 關于SQL Server 2000的page、extents和index結構，參考：MSDN - Pages and Extents, MSDN - Table and Index Architecture。

??? Page Split（頁切分）
??? SQL Server在Insert/Update時，如果要更新的page已經存儲滿，無法容納下新的數據，則SQL Server將這個page的一半數據切分出來，重新分配一個page存放，然后再進行Insert/Update操作，將以滿的數據頁切分成兩個數據頁的操作叫做page split。
??? 不管是data page還是index page，都會發生page split。在Insert操作時，如果page上的free space小于要插入的記錄大小，將進行page split；在Update時，如果table中存在變寬字段，變寬字段的長度變大導致原page上free space不夠，將進行page split。

??? Index Fragmentation（索引碎片）
??? SQL Server的index fragmentation有兩種：external fragmentation和internal fragmentation。
??? External fragmentation:
??? Index page的邏輯順序不連續時，叫做external fragmentation。Index建立時，index page的存儲在邏輯上都是連續的。在進行insert操作時，可能需要在兩個索引之間插入這個新的索引。如果在索引插入位置的index page還有足夠的空間，則會直接在這個index page中插入新的索引值；如果在這個index page上空間已滿或者不夠新的索引值所需空間，則SQL Server會進行page split，將插入位置的index page一部分數據移走，以釋放出空間來插入新的索引，被移走的數據在其它位置重新分配新的page存放。這樣，隨著insert操作的增加，index page在邏輯上的連續程度就越來越低。
??? 下圖示例索引剛剛建立好之后邏輯上是連續時的索引結構：
???
??? 假如此時需要插入索引值為2的新索引，則插入之后的索引結構如下圖：
???
??? 插入之后index page結構在邏輯上變得不連續。
??? 在通過index返回特定記錄，或者返回不用指定排序的記錄集時，external fragmentation不會對查詢性能產生太大影響。當需要返回指定排序的記錄集時，排序過程中需要對邏輯上非連續的index page進行額外處理，對于大數據量的表，如果index page非常多，external fragmentation很嚴重，就需要消耗高昂的查詢成本。另外，external fragmentation對緩存效率產生影響。
??? External fragmentation使用兩個方面的指標來描述，page的連續程度和extent的連續程度。
??? Internal fragmentation：
??? Index page中如果存儲空間未達到最大存儲容量，叫做internal fragmentation。不考慮fill factor因素的影響，index建立時，索引結構邏輯上連續，并且每個index page都存儲滿，被充分利用。Delete操作會造成index page出現空閑；External fragmentation的示例中，insert操作時的page split也造成index page出現空閑。
??? 嚴重的internal fragmentation，造成index page占用比實際所需大得多的存儲空間。查詢中進行index scan時，增加了logical READS、I/O等操作，產生性能問題。
??? Internal fragmentation使用頁的平均頁的空閑程度/利用程度作為指標。
??? Fill factor:
??? 如果有設置或者是SQL Server自動維護了一個fill factor值，則在創建索引時，每一個index page都不會存儲滿，而根據fill factor值預留一部分空閑空間。在external fragmentation的示例中，假如第一個index page沒有存儲滿，則在插入索引值為2的新索引時，就不需要將這個index page進行split，從而可以改善insert操作。
??? Fill factor用于需要頻繁進行insert/update操作的表中，避免大量的page split出現。顯然，fill factor的使用類似于internal fragmentation，但對大量的insert操作以及各種data page的結構帶來極大的改善。對于fill factor，不太方便準確的評估什么樣的值最佳，Microsoft建議讓SQL Server自動維護。不恰當的fill factor設置，同internal fragmentation一樣，影響SQL Server性能。

??? DBCC SHOWCONFIG
??? 用于顯示數據、索引fragmentation信息。
??? DBCC SHOWCONTIG (TblUserItem,PK_TblUserItem)
??? 顯示表TblUserItem中索引PK_TblUserItem的fragmentation信息。
??? DBCC SHOWCONTIG (TblUserItem) WITH ALL_INDEXES
??? 顯示表TblUserItem所有索引的fragmentation信息。
??? DBCC SHOWCONTIG WITH ALL_INDEXES
??? 顯示當前數據庫中所有索引的fragmentation信息。
??? 執行的結果示例如下：
???DBCC SHOWCONTIG 正在掃描 'TrackServer' 表...
表: 'TrackServer' (1632991252)；索引 ID: 0，數據庫 ID: 9
已執行 TABLE 級別的掃描。
- 掃描頁數................................: 217
- 掃描區數..............................: 44
- 區切換次數..............................: 43
- 每個區的平均頁數........................: 4.9
- 掃描密度 [最佳計數:實際計數].......: 63.64% [28:44]
- 區掃描碎片 ..................: 97.73%
- 每頁的平均可用字節數........................: 628.1
- 平均頁密度(滿).....................: 92.24%
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。??? Page Scanned:實際掃描的page數量。可以從每個數據行的大小、總的行數大致計算出實際所需的data page數量，如果Page Scanned數量遠遠超過計算出的實際data page數量，則internal fragmentation比較嚴重。
??? Extents Scanned:理想值為將Page Scanned/8圓整為最小整數。如果Extents Scanned大于理論值，則存在一定程度的external fragmentation。
??? Extent Switches:理想值為Extents Scanned減1，超過這個值說明存在external fragmentation。
??? Avg. Pages per Extent:理想值為8，小于8則存在external fragmentation。
??? Scan Density [Best Count:Actual Count]:這是DBCC SHOWCONTIG返回的最有意義的一個值，為理想的extents數量比實際的extents數量，反應external fragmentation的重要統計信息之一。理想值為100%，不能低于60%。
??? Logical Scan Fragmentation:另外一個非常有意義的值，指示page的非連續程度，反應external fragmentation的重要統計信息之一。應當在0%-10%之間，不能高于15%。
??? Extent Scan Fragmentation:指示extents的非連續程度，理想值為0%。
??? Avg. Bytes Free per Page:平均每page上的空閑字節數。過高的值表明存在internal fragmentation，但是需要將fill factor因素排除。
??? Avg. Page Density (full):與Avg. Bytes Free per Page對立的一個百分比參數，較低的值表明存在internal fragmentation。
??? 另外DBCC SHOWCONTIG還有幾個可選參數可以使用，具體參考Online Help。

??? Resolving fragmentation issues
??? 1. Drop原來的索引再重建這些索引
??? 這個過程中索引被drop和rebuild，會使這個期間所有的查詢阻塞；對所有的clustered index和non-clustered index使用該方法，可能會導致non-clustered index重建兩次。
??? 優點是索引徹底重建，達到最理想的狀況。如果external和internal fragmentation都相當嚴重，應當使用該方法。
??? 2. 使用DROP_EXISTING子句
??? 使用DROP_EXISTING子句，可以避免non-clustered index被重建兩次。
??? 3. DBCC DBREINDEX
??? 可以僅指定Table名字，而無須指定索引名稱，該命令自動將Table的所有索引進行重建，這樣比寫多條DROP INDEX和CREATE INDEX語句進行操作要方便。這個命令同時將Table的PRIMARY KEY和UNIQUE約束、STATISTICS重建，無須額外對這些約束和STATISTICS進行操作。
??? DBCC DBREINDEX能夠比較充分的利用多CPU進行處理，對數據量相當大和fragmentation非常嚴重的表操作時會比較快。
??? 該方法在一個事務中完成操作，在數據文件中需要有足夠的free space來滿足將所有的索引及相關的一些對象進行重建，否則操作可能失敗，或者是重建的不十分徹底，例如重建完后logical fragmentation可能仍大于0。對于數據量非常大的表，所需的free space也更多，應當特別注意這一點。
??? 4. DBCC INDEXDEFRAG
??? DBCC INDEXDEFRAG分兩個步驟進行操作，首先對各個index page進行壓縮，釋放出多余的page；然后重組index page的各個根節點，使得index page的邏輯順序與物理存儲順序一致，即在物理存儲方向上保證邏輯順序是連續的。
??? 4種方法中，其它三種都必須在數據庫offline情況下進行，因為在操作期間會導致使用這些索引的所有查詢阻塞。DBCC INDEXDEFRAG可以在數據庫online的情況下執行，但是整理不夠徹底。因為一方面，在執行期間會忽略被lock的 index page，另一方面它不會新分配page進行重排序，只是在原來已分配的page空間里進行重組。這個命令的目標也就是使index page的邏輯順序與物理存儲順序一致，如果邏輯上相鄰的兩個page或extent的物理存儲之間存在間隔，DBCC INDEXDEFRAG不會采取操作消除這種物理存儲間隔。因此如果index page所占用的空間非常大時，訪問index page空間可能會增加磁頭定位和移動的開銷，從而在一定程度上增加了I/O操作成本。

?? 專家建議：60%<Scan Density<75%、10<Logical fragmentation<15時，使用DBCC INDEXDEFRAG；Scan Density<60%、Logical fragmentation>15時，使用DBCC DBREINDEX。

??? 另外，在table設計方面，可以考慮以下幾點：
??? 1. 對于Insert/Update操作頻繁的table，選擇一個合適的fill factor。
??? 2. 將變寬字段設計為等寬字段。例如物料號、訂單號、客戶代碼、供應商代碼等。
??? 3. 設立刪除標記而不是物理刪除數據。
??? 例如有些大型系統，一個對象可能會有幾十個字段。通常情況下的做法是用一個table容納所有這些字段，但是出于系統訪問效率方面考慮，可以使用兩個 table來存儲。主表存放關鍵性、訪問最頻繁的字段屬性，盡量不使用變寬字段；從表存放附加的、描述性的、訪問比較少的字段屬性。這樣雖然是一對一關聯的表，但是對于大多數情況下對于只需要訪問主表屬性的查詢，可以做到極大的提高訪問性能。

??? 關于fill factor 說明：

在創建聚集索引時，表中的數據按照索引列中的值的順序存儲在數據庫的數據頁中。在表中插入新的數據行或更改索引列中的值時，Microsoft SQL 2000?? 可能必須重新組織表中的
數據存儲，以便為新行騰出空間，保持數據的有序存儲。這同樣適用于非聚集索引。添加或更改數據時，SQL?Server?可能不得不重新組織非聚集索引頁中的數據存儲。向一個已滿
的索引頁添加某個新行時，SQL?Server?? 把大約一半的行移到新頁中以便為新行騰出空間。這種重組稱為頁拆分。頁拆分會降低性能并使表中的數據存儲產生碎片。

使用fill??factor選項指定當使用現有數據創建新索引時，Microsoft SQL??Server??應使每一頁填滿的程度。由于?SQL?Server?必須在填充時花費時間分割這些頁面，所以fill?? factor?百分比會影響系統性能。???
fill?factor?百分比僅在創建索引時使用。這些頁面都不可能被維護在任何特定的飽滿水平上。???
fill?factor??的默認值為?? 0；其有效值是從?0?到?100。fill?factor?的值為0?并不表示頁面的填滿程度為?0%。類似于?fill factor?設置為100?? 的情況，SQL?Server?? 在fill?factor值為0時，會用頁面全部為數據的頁來創建聚集索引，用頁面全部為數據的葉子頁來創建非聚集索引,與fill?factor?設置為100?的情況不同的是，SQL?? Server?? 在索引樹的高層級別上預留空間。很少有理由去改變?? fill?? factor?? 的默認值，因為可以使用?CREATE?? INDEX?命令來覆蓋它,較小的fill?factor??值將導致?SQL?Server?以不飽滿的頁面創建新索引。例如，將?fill?factor??值設置為10?? 對于想在一個最終將保持較少數據的表上創建索引是合適的。越小的??fill?factor?值將導致每一個索引占用更多的存儲空間，但同時也允許以后可不進行頁面拆分進行插入操作。???
如果設置?? fill?factor?值為100，SQL?Server?以100%?? 的飽滿度創建聚集和非聚集索引。設置fill??factor?的值為100?僅對只讀表是合適的，
因為數據從來不被添加到此類表中。

一般的填充因子設置策略:??
? 數據變化越頻繁,填充因子越小??
? 數據越少變化,填充因子越大,
? 對于數據不變化的表,填充因子設置為100

?

總結

以上是生活随笔為你收集整理的索引分类的全部內容，希望文章能夠幫你解決所遇到的問題。

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