對堆建聚集索引再DROP在我看來是除了收縮數據庫之外最2的事了。 如果你通過sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片，絕對不要通過建立聚集索引再刪除聚集索引來整理堆碎片。好的做法應該是建立聚集索引之后不再刪除，已經有非常多的資料闡述如何選擇一個理想的聚集索引鍵--窄，很少變動，唯一，自增。Kimberly有一篇文章對此做了一個總結:Ever-increasing clustering key - the Clustered Index Debate..........again!(注意，是基于SQL Server 2005版本),對此我也有一個例子：An example of a nasty cluster key。 你也可以在SQL Server 2008中通過ALTER TABLE ... REBUILD來清除堆碎片，但這個做法和建立聚集索引后再刪除同樣邪惡。 如果你想問為什么我對此甚有成見？好吧，那我解釋一下：非聚集索引中每一行都會指向一個RID或是聚集索引鍵的鏈接（詳情請看：What Happens if I Drop a Clustered Index?）,這個鏈接會以下面兩種方式之一出現：
如果非聚集索引所在的表是堆，那么這個鏈接就是一個RID。
如果非聚集索引所在的表是聚集索引，那么這個鏈接就是聚集索引鍵。 如果你希望對此有更多了解，請看文章底部的鏈接。 因此不難看出，如果你希望將堆變為聚集索引，那么非聚集索引的所有RID就失效了，因此所有的非聚集索引都需要被重建。同樣，如果刪除聚集索引鍵，那么所有非聚集索引上存儲的聚集索引鍵都會失效，因此也需要重建所有的非聚集索引。 簡單點說，如果你建立再刪除聚集索引后，所有的非聚集索引都會被重建兩次。 如果你使用SQL Server 2008的ALTER TABLE ... REBUILD來整理堆碎片，那么同樣也需要重建所有的非聚集索引，因為所有的RID都會變動。 那么，如果對于“重建”聚集索引呢？這取決于SQL Server的版本以及你是進行rebuild索引亦或是改變索引。一個常見的誤區是對表進行分區將會改變聚集索引鍵，但事實上不會。對于那些會引起非聚集索引重建的操作，請看如下列表:Indexes From Every Angle: What happens to non-clustered indexes when the table structure is changed?。
您可能感興趣的文章:
SQL Server誤區30日談 第28天 有關大容量事務日志恢復模式的誤區
SQL Server誤區30日談 第27天 使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
SQL Server誤區30日談 第26天 SQL Server中存在真正的“事務嵌套”
SQL Server誤區30日談 第25天 有關填充因子的誤區
SQL Server誤區30日談 第24天 26個有關還原(Restore)的誤區
SQL Server誤區30日談 第23天 有關鎖升級的誤區
SQL Server誤區30日談 第22天 資源調控器可以調控IO
SQL Server誤區30日談 第21天 數據損壞可以通過重啟SQL Server來修復
SQL Server誤區30日談 第20天 破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
SQL Server誤區30日談 第19天 Truncate表的操作不會被記錄到日志
SQL Server誤區30日談 第18天 有關FileStream的存儲，垃圾回收以及其它
SQL Server誤區30日談 第17天 有關頁校驗和的誤區
SQL Server誤區30日談 第16天 數據的損壞和修復
SQL Server誤區30日談 第15天 CheckPoint只會將已提交的事務寫入磁盤
SQL Server誤區30日談 第14天 清除日志后會將相關的LSN填零初始化
SQL Server誤區30日談 第13天 在SQL Server 2000兼容模式下不能使用DMV
