索引是數據庫引擎中針對表(有時候也針對視圖)建立的特別數據結構，用來幫助查找和整理數據。索引的重要性體現在能夠使數據庫引擎快速返回查詢 結果。當對索引所在的基礎數據表進行修改時(包括插入、刪除和更新等操作)，會導致索引碎片的產生。當索引的邏輯排序和基礎表或視圖的物理排序不匹配時， 就會產生索引碎片。隨着索引碎片的不斷增多，查詢響應時間就會變慢，查詢性能也會下降。在SQL Server 2005中，要解決這個問題，要么重新組織索引要么重新生成索引。
重新組織VS重新生成
修復索引碎片的方法有兩種：重新組織索引或重新生成索引。重新組織索引會對最外層數據頁里的數據進行重新排序，並壓縮索引頁。重新組織的過程中 不會添加任何額外的數據，所以索引可能還殘留着一定程度的碎片。重新組織索引操作不會占用很多系統資源，在運行過程中外部進程也能夠對該索引所在的數據表 進行查詢，所以能夠說是聯機(online)執行。
重新生成索引操作基本上刪除掉目標索引並創建一個新索引。舊索引中的任何碎片都會被刪除，新索引的邏輯排序將和對象的物理排序相匹配。由於整個 過程需要刪除索引並重新創建，所以外部進程無法訪問數據表，而且訪問性能也大受影響。事實上，在重新生成索引的過程中，其他進程並不能完全鎖定數據表。這 是重新生成索引的一大障礙。
聯機重新生成索引
SQL Server 2005引進了以聯機方式重新生成索引的能力，這樣其他進程就能夠在此過程中正常訪問數據表，而且也就無需限制在非繁忙時段進行索引重新生成操作。
要做到聯機操作，數據庫引擎會采取若干特別配置，以便在重新生成索引的同時允許對該索引的訪問。首先，將保留原始索引以供用戶讀取數據和對數據 進行修改。其次通過行版本控制(row versioning，在tempdb數據庫存儲舊版本的行的過程)使事務讀取保持連貫性。在重新生成過程中，仿效舊索引創建一個新索引。任何改變原始索 引的數據修改操作都會在重新生成索引的過程中被SQL Server引用到新索引中。新索引不能讀取，只能對其進行寫入操作。關鍵的一點是，聯機重新生成索引過程中必須為兩個並發索引提供足夠的磁盤空間來容納 數據。重建進行的過程中，假如原始索引發生改變，SQL Server會利用一個映射索引來確定新索引中哪些記錄需要進行相應修改。一旦重新生成的過程順利完成，任何查詢或數據修改操作都將指向新索引，同時刪除 原始索引。
例子
聯機重新生成索引的過程和一般的重新生成索引過程沒有太大區別。但是，能夠通過幾個方法來完成整個重生過程。第一個方法就是簡單地刪除索 引，CREATE INDEX語句后加上一條DROP INDEX就能夠。用這種方式重新生成索引會使數據表保持沒有索引的狀態直到新索引完全創建完畢。所以並不推薦使用這種方法來刪除索引。
假如使用DROP_EXISTING語句，仍然能夠用CREATE INDEX來重新生成索引。這個特點使我們能夠改變指定索引的定義，並且使數據庫管理員能夠把索引的存儲位置改到另外一個文檔組或分區里。
ALTER INDEX語句使我們能夠重新生成數據表上的聚集索引和任何非聚集索引。這個語句的缺點是，您不能改變索引的定義。這些語句都含有能夠聯機生成索引的選項。
以下的語句是用來重新生成FlightHistory表上的聚集索引(位於FlightID列)。在這個過程中，既存的索引將會被刪除，但是由於指定了ONLINE選項，所以在操作過程中該索引還能夠被訪問。
| 以下是引用片段： CREATE CLUSTERED INDEX cl_FlightHistory_FlightID ON FlightHistory(FlightID) WITH(DROP_EXISTING = ON, ONLINE = ON) |
下面的語句和上面的很相似，但是改變實際的索引定義，包含了一個額外列。索引還是按照相同的方式重新生成。
以下是引用片段：CREATE CLUSTERED INDEX cl_FlightHistory_FlightID ON FlightHistory(FlightID ASC, FlightDate ASC)
WITH(DROP_EXISTING = ON, ONLINE = ON)