SQL Server誤區30日談 第29天 有關堆碎片的誤區。本站提示廣大學習愛好者：（SQL Server誤區30日談 第29天 有關堆碎片的誤區）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server誤區30日談 第29天 有關堆碎片的誤區正文
誤區 #29:可以經由過程對堆建集合索引再DROP落後行堆上的碎片整頓
Nooooooooooooo!!! 對堆建集合索引再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?。
