《Microsoft Sql server 2008 Internals》索引目錄：

　　前一節主要介紹了索引的更新機制和索引的轉向指標，以及更新的位置和修改單個行（或單索引對應的若干行）。如果你修改單個操作（Insert,update,Delete）或使用（BCP、BLUK Insert）命令的多行，而表有多個索引時，你得關注另外一些主題。SQL Server 2008提供了兩種維護表索引的策略：表級修改和索引級修改。查詢優化器會根據預計的執行成本決定使用相應的策略。

■表級vs索引級資料修改
　　表級修改有時也叫row-at-a-time,索引級修改有時也叫index-at-a-time。在表級修改時，行被修改時每個行所有的索引被保留。如果更新流沒有被以任何形式排序，SQL Server會大量的隨機索引訪問，每個更新行每個索引一次訪問。如果更新流已經排序（只能有一個排序），因此非隨機索引訪問最多隻能在一個索引時發生。

　　索引級修改時，SQL Server收集所有要被修改的行，併為每個索引排序這些行，換句話說，排序操作和索引操作是對應的。對每個索引，更新被合併到索引（的更新），每個索引頁最多會被訪問一次，即便多個更新屬於一個單個索引葉級頁。

　　很顯然，如果更新是小的（即少量的瘦的行），表和索引是可度量的，查詢優化器通常會考慮表級修改作為最佳選擇。絕大多數OLTP操作都是表級修改。另一方面，如果更新相對較大，表級修改需要大量的隨機I/O操作，可能會在每個索引的每個葉級頁讀寫多次。在此情況下，索引級修改提供了更佳的效能。兩種策略都會需要大量的日誌記錄。另外，你可以通過查詢執行計劃來決定使用表級或索引級策略。

■管理索引結構

　　SQL Server自動維護你的索引。當你增加新行時，系統會自動插入這些行在一個（有聚集索引的）表的正確位置，或增加新的葉級行到你的非聚集索引以指向新的資料行。當你移去這些行時，SQL Server自動從非聚集索引索引中刪除相關的葉級行。

■Dropping Indexes

　　使用Create Index命令建立的索引和支援約束的索引這兩種方式會影響刪除索引的方式。Drop Index命令允許你刪除僅僅使用Create Index命令建立的索引。為了刪除支援約束的索引，你必須使用Alter table命令先刪除約束。而且，包括刪除主鍵、惟一的約束和引用這些它們的外來鍵約束，如果不想麻煩，你可以使用以下方法：

１使用ALTER Index命令。更多引數，請看MSDN:

２使用Create Index命令帶DROP_Indexing選項，不過此時重建命令不再適合於支援約束的索引，即只能drop了。

■Alter Index

SQL Server 2005提供了Alter Index命令，該命令允許你使用單個命令來呼叫以前版本所需的多個風格迥異的命令集（包括sp_Indexoption,Update Statistics,DBCC DBREINDEX和DBCC INDEXDEFRAG等）才能完成的功能。具體功能可以參看MSDN:（http://msdn.microsoft.com/zh-cn/library/ms188388.aspx）

１、Rebuiding an Index（重新生成索引）

　　重新生成索引代替了“DBCC DBREINDEX”命令，可以看作是CREATE INDEX命令加了DROP_EXISTING選項。然而，這個選項也允許索引被移動或被分割槽。

２、禁用索引

　　禁用一個索引會使它完全不可用，它也不能被用來為任何操作來查詢行。同時也意味著它不會隨著資料的修改而更新（，從而導致過時）。你可以用一個命令禁用一個或全部索引，記住，沒有Enable選項來恢復你的禁用。道理很簡單，因為索引被禁用後不再被維護，也就失去了意義，必須被完全rebuilt。重新啟用索引（無論是離線還是聯機，）其實質是ALTER INDEX加了一個REBUILD選項。禁用索引主要是在SQL Server升級或打補丁時用到，但也有幾個有趣的應用場景。第一，你可以在故障排除時想臨時忽略索引時。第二，載入資料前不使用非聚集索引時，但是請注意不要禁用聚集索引。如果你禁用某表的聚集索引，這個表的資料將不可用，因為聚集索引的葉級是資料。禁用聚集索引就等於禁用了表。當然，如果你的資料是按照聚集索引排序（即便不是遞增的聚集鍵），這樣所有新的資料將會加在表的尾部，此時，禁用所有的非聚集索引有助於改善載入效能。一旦所有的資料被載入完成，你不需要提供完整的索引定義就可以rebuild非聚集索引。索引被禁用時，所有的元資料被儲存。

３、更改索引選項

　　Create Index操作的大多數選項可以用於Alter Index命令。比如ALL_ROW_LOCKS,ALLOW_PAGE_LOCKS,INGORE_DUP_KEY,FILLFACTOR,PAD_INDEX,STATITICS_NORECOMPUTE,MAX_DOP和SORT_IN_TEMPDB等。

４、(Reorganizing an index)重組索引

參照MSDN的解釋，重組索引就是使用最少系統資源重新組織索引。通過對葉級頁以物理方式重新排序，使之與葉節點的從左到右的邏輯順序相匹配，進而對錶和檢視中的聚集索引和非聚集索引的葉級進行碎片整理。重新組織還會壓縮索引頁。壓縮基於現有的填充因子值。

■（Detecting Fragmentation）探測碎片

　　正如我們前面所看到的例子那樣，sys.dm_db_index_physical_stats為每個索引的每一Level返回一行。然而，表被分割槽時，其實分割槽是被看作一個表，因此，DMV實際是為每個索引的每個分割槽的每個Level返回一行。對於僅有in-Row資料（即沒有row-overflow或LOB頁）和僅有一個預設分割槽的小索引，我們可能只得到兩到三行返回值（每個索引Level一個）。但是如果有多個分割槽和額外的row-overflow及LOB頁分配單元時，我們可能看到更多行。例如，一個包含row-Overflow資料，為row-overfow分配單元建有11 個分割槽，有兩個Level深度的表，它的聚集索引有33行（2LevelsX11分割槽+11個為row_Overflow分配單元的分割槽），這個結果由sys.dm_db_index_ physical_stats（http://msdn.microsoft.com/zh-cn/library/ms188917.aspx）整理報告返回。

　　這裡我們再提一下返回結果的幾個列：

(1)Forwarded_record_count

Forwarded記錄（前面討論過）可能僅僅在一個Heap，並且當包含可變長度列的行因大小改變而不能在原位置時發生。如果表有大量的Forwarded記錄，掃描一個表可能效率非常低下。

(2)Ghost_Record_Count 和version_ghost_record_count

　　Ghost記錄是那些物理上還在一個頁，而邏輯上已經被移走的行。在SQL Server中後臺執行緒清理Ghost記錄，但是在清理之前，新記錄不能被插入在它們所佔的位置。因此，如果有大量的Shost記錄，表就有了內部整理的缺陷（即該表將佔去更多的頁，花更多時間來掃描）而不利（在相關頁沒有空間來插入新記錄以避免額外的整理）。一個Ghost記錄的子集用Version_ghost_record_count來度量。這個值　對應被孤立的快照隔離事務保留的記錄數量。它們直到相關的事務被提交或回滾時才被清除。

■（Removing Fragmentation）移除碎片

　　如果碎片變得非常嚴重，會影響到查詢效能，有幾個選項可以移除它。你可能想要知道多嚴重才是“嚴重”，首先，碎片不總是一件壞事。最大的效能代價來自於你的程式需要對資料執行一個已擬定的掃描時，整理資料被喚醒。如果，你的應用僅僅一兩行資料，那麼表或索引資料是否按邏輯順序或物理連續就不那麼重要，甚至它在磁碟上的位置完全隨機（也影響不大）。如果你有一個好的索引來找到你感興趣的行，SQL Server能高效地找到一個或幾行，即便它們剛好被物理定位。

　　如果你正在做一個索引的排序掃描（比如在一個有聚集索引的表上進行表掃描，或一個非聚集索引上的葉級掃描），最常被推薦的是：如果avg_fragmentation_in_percent值位於5-20，則應該重新組織索引以移去碎片。重新組織一個索引會讓葉級頁返回原始的定義填充因子，並重新排列葉級頁經糾正邏輯核算碎片，使用索引原始佔用的相同頁。沒有新頁被分配，因而這個操作比rebuilding索引更有效利用　空間。

如果avg_fragmentation_in_percent值大於30，你應該考慮完全重建索引。這將移去所有的碎片，但並不確保完全削除碎片（也就是我們通常說的，手術過了但不一定成功）。如果資料庫的自由空間是自身的碎片，你或許沒有足夠的連續空間來移除所有的區塊之間的縫隙。此外，其他正在進行的工作需要重新分配新區塊，而此時你的索引正在重建，那麼對兩個程序的已分配的區塊可能因為交錯而終止。

　　整理被用設計用來從索引的葉級移去邏輯碎片同時保持索引聯機並儘可能可用。當整理一個索引時，SQL Server在B樹上得到一個意向獨佔鎖。鎖定的獨佔頁剛好是被操作的單個頁。SQL Server 2008中使用ALTER INDEX命令來初始化整理。

常用的移除碎片的格式如下：

ALTER INDEX { index_name | ALL } ON REORGANIZE [ PARTITION = partition_number ] [ WITH ( LOB_COMPACTION = { ON | OFF } ) ]
　　相比而言，REORGANIZE選項的功能比SQL Server 2000的INDEXDEFRAG強了很多，它支援分割槽索引。如前所述，每個索引被一個特定的填充因子（fillfactor）所建立，初始的填充因子值以索引元資料儲存，因此，整理碎片被請求時，SQL Server可以inspect該值。在整理期間，SQL Server試圖在一個葉級頁重建（reestablish）初始填充因子（如果它比當前值大）。整理被設想來使資料更緊湊，可能每頁放更多的行，每頁增加更充滿的百分比。SQL Server可能終止並在整理後從索引移去頁。如果當前填充因子大於初始值，SQL Server不能通過移動行來消減頁的飽滿度。壓縮演算法（按邏輯順序）檢查鄰近的頁，以確定是否有空間來從後頁移動行到前頁。自SQL Server 2005起，這個程序通過檢視８個邏輯連續頁的小滑塊甚至更有效。它決定周圍連續的８個頁是否有足夠的行以允許一個單頁被清空或移走，並在合適時移走行。

　　SQL Server 2005也新增了選項來緊縮(compact)LOB頁，預設選項是ON。重組指定的聚集索引會在緊縮葉級頁之前緊縮所有包含在聚集索引中的ＬＯＢ列。重組非聚集索引會緊縮所有非鍵列的LOB列。

　　在SQL Server 2000中，唯一的緊縮表中LOB的方法是unload+reload　LOB資料。SQL Server 2005起，LOB緊縮操作會找到低密度的區塊（使用低於75%）。它從低密度的整齊區塊移去頁，並從已經分配到ＬＯＢ分配單元的其他整齊區塊的可用空間來存放這些資料。該功能允許磁碟空間更好的被利用（特別是低密度LOB區塊）。無論是在緊縮階段或其他後續階段，都沒有新區塊（extent)被分配。

　　重組操作的第二階段其實是移動資料到in-row分配單元的新頁，目的是使資料的邏輯順序與物理順序一致。索引保持聯機因為在一個操作中同時只有兩個頁被處理（類似於堆排序或平滑排序。）下面的例子是一個重組的實際程序。

　　假如一個datetime列索引，週一的資料邏輯排列在週二前，週二在週三前，依次類推。如果，週一的資料在88頁，週二的資料在50頁，週三在100頁，週四在77頁。物理與邏輯絲毫不匹配，出現邏輯碎片。當整理一個索引時，SQL Server判斷第一個物理頁屬於頁級（本例的頁50），第一個葉級的邏輯頁（頁88，擁有周一的資料），通過使用一個額外的新頁作為臨時儲存區域來交換兩頁的資料。交換過後，第一個邏輯頁的資料是週一資料，在頁50，最小序號的物理頁。在兩兩交換後，所有的鎖和閂被釋放，最後一個被移動頁的鍵值　被儲存。演算法的下一次迭代使用儲存的鍵值來找到下一個邏輯頁－－週四的資料，頁88。下一個物理頁是77，週二的資料。因此，下一個交換是週二的資料位於77頁，週四的資料位於88頁。直到無需交換為止。注意：混合區塊上的頁不會整理。

　　你需要了解一些使用REORGANIZE選項的限制。肯定，如果索引被禁用，則不能被整理碎片。而且，移去碎片的過程需要工作在獨立的頁，你可能會在重組一個（ALLOW_PAGE_LOCKS為OFF的）索引時，丟擲一個錯誤。如果一個併發的聯機索引被建立在相同的索引或另外一個重組相同索引的程序時重組不會發生。

■（Rebuilding an Index）重新生成索引

　　你有幾種方式可以完全重建索引。可以使用一個簡單的DROP INDEX加CREATE INDEX的組合，但這最不可取。特別是，這種方法重建一個聚集索引時，所有的非聚集索引在drop聚集索引時會全部重建。非聚集索引這麼處理是必需的，因為它要改變葉級的行定位從聚集鍵值到行IDs。於是，當你重建聚集索引時，所有非聚集索引必須被重建。而且，如果索引支一個Primary KEY或Unique約束時，你不能使用drop index命令，除非你首先刪除所有的外來鍵。不推薦這樣做。

　　更好的一種方式是使用ALTER INDEX命令或使用帶DROP_EXISTING子句的CREATE INDEX。下例是重建Production .TransactionHistory表上的索引PK_TransactionHistory_TransactionID

ALTER INDEX PK_TransactionHistory_TransactionID ON Production.TransactionHistory REBUILD; CREATE UNIQUE CLUSTERED INDEX PK_TransactionHistory_TransactionID ON Production.TransactionHistory (TransactionDate, TransactionID) WITH DROP_EXISTING;

　　儘管Create方法需要知道索引架構，它實際上更強大，提供了更多的自定義選項。你可以改變標記索引的列，改變uniqueness屬性，或者改變一個非聚集索引為聚集索引，只要表上不存在一個聚集索引。你也可以在重建時指定一個新的檔案組或分割槽架構。注意，如果你確實更改了聚集索引屬性，所有的聚集索引必須被重建，但是僅僅一次。（第一個方法是兩次）

　　當使用ALTER INDEX命令重建索引時，非聚集索引不需要重建，因為此時並沒有更改索引的定義。然而，你可以指定取代所有的索引名，並請求所有索引被重建。使用ALTER INDEX的另一個優勢是你可以僅僅指定一個分割槽來重建（通過sys.dm_db_index_physical_stats檢視）

#聯機索引生成（Online Index Building）

　　重建索引的任何方法的預設行為是SQL Server啟用一個該索引的獨佔鎖，因此，索引重建時完全不可用。如果是聚集索引，整表不可用。非聚集的則是一個表的共享鎖（不能修改，但可以Select），此時查詢的效能可能大打折扣。

　　SQL Server 2005新增了一個選項以聯機重建一個或多個索引---“ONLINE”。在Alter Index和Create Index中可用，也可以加DROP_EXISTING或不加。一個基本語法示例如下：

ALTER INDEX PK_TransactionHistory_TransactionID ON Production.TransactionHistory REBUILD WITH (ONLINE = ON);

　　聯機重建同時維護兩個索引的副本：源和目標（後者是新的）。目標被用於等待索引重建時的任何變化。所有的讀都是從源讀出，修改被應用於源。SQL Server行級版本被使用，因此任何人從索引中提取資訊時能讀到連續的資料。

下圖展示了這個過程的三個階段：

　　實際處理過程可能略有不同，這取決於索引是否被初始化重建，以及是否聚集索引。

　　10個步驟如下：

（１）一個共享鎖（S-LOCK）被索引啟用，以防止任何資料修改性的查詢，一個意向共享鎖（IS-LOCK）被啟用。

（２）建立一個索引，與源同樣結構，並被標記為只寫

（３）索引上的共享鎖被釋放，僅保留意向共享鎖

（４）在源（索引）的一個版本掃描（Versioned scan）開始，在掃描期間的修改將被忽略，掃描後的資料被複制到目標（索引）

（５）所有隨後的修同時寫到源和目標。讀僅僅使用源

（６）源的掃描和複製到目標持續進行，不影響正常操作。SQL Server使用一個所有權方式來調和明顯的衝突（比如掃描被插入到新索引前記錄正被刪除。

（７）掃描完成

（８）一個架構修改鎖（Sch-M-lock），各種鎖中最嚴格的鎖，被啟用以確使表完全不可用。

（９）源索引被drop，元資料被更新，目標索引被讀寫

（１０）架構修改鎖釋放。

　　建立一個新的非聚集索引準確地呼叫以上步驟，除了沒有目標索引，因而版本掃描在基表中執行，寫操作僅僅在目標索引。一個聚集索引的重建與非聚集索引相似，只是沒有架構更改（索引鍵或uniqueness屬性）

　　對於建立一個新的聚集索引，或重建一個帶有架構更改的聚集索引，有一些區別。首先，一箇中介對映索引被用於轉換源和目標的物理結構。其次，所有已存在的非聚集索引在基表被建立時被同時重建。例如，建立一個帶有兩個非聚集索引的Heap上的聚集索引呼叫以下步驟：

（１）建立一個新的只寫聚集索引

（２）基於新聚集索引建立一個新的非聚集索引

（３）基於新聚集索引建立另一個新的非聚集索引

（４）Drop該Heap及兩個原始的非聚集索引

　　操作完成前，SQL Server將立刻維護６個結構。聯機索引重建並不是真的被考慮作為效能增強，因為離線明顯更快，而且所有的結構不需要同時維護。它其實是一個可選項－－當你需要7*24完全不間斷時，可以通過它移去所有的碎片或重建立填充因子。

　　關於聯機索引重建需要注意：

A:如果索引包含LOB列，聯機索引操作不可用。也就是說如果表包含LOB列，聚集索引將不能被聯機重建。聯機操作在指定非聚集索引包含LOB列也會被阻止

B:聚集索引或非聚集索引的一個單個分割槽不能被聯機重建。

　　本文主要介紹了Alter Index的相關內容，關於索引的內容將會告一段落，下一章是關於Special Storage（特定儲存）的相關內容。

邀月注：本文版權由邀月和CSDN共同所有，轉載請註明出處。助人等於自助! [email protected]