主頁 > 知識庫 > SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)

SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)

誤區(qū) #29:可以通過對堆建聚集索引再DROP后進(jìn)行堆上的碎片整理
Nooooooooooooo!!!

     對堆建聚集索引再DROP在我看來是除了收縮數(shù)據(jù)庫之外最2的事了。
     如果你通過sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片，絕對不要通過建立聚集索引再刪除聚集索引來整理堆碎片。好的做法應(yīng)該是建立聚集索引之后不再刪除，已經(jīng)有非常多的資料闡述如何選擇一個理想的聚集索引鍵--窄，很少變動，唯一，自增。Kimberly有一篇文章對此做了一個總結(jié):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?）,這個鏈接會以下面兩種方式之一出現(xiàn)：

如果非聚集索引所在的表是堆，那么這個鏈接就是一個RID。
如果非聚集索引所在的表是聚集索引，那么這個鏈接就是聚集索引鍵。
    如果你希望對此有更多了解，請看文章底部的鏈接。
    因此不難看出，如果你希望將堆變?yōu)榫奂饕敲捶蔷奂饕乃蠷ID就失效了，因此所有的非聚集索引都需要被重建。同樣，如果刪除聚集索引鍵，那么所有非聚集索引上存儲的聚集索引鍵都會失效，因此也需要重建所有的非聚集索引。
    簡單點(diǎn)說，如果你建立再刪除聚集索引后，所有的非聚集索引都會被重建兩次。
   如果你使用SQL Server 2008的ALTER TABLE ... REBUILD來整理堆碎片，那么同樣也需要重建所有的非聚集索引，因?yàn)樗械腞ID都會變動。
    那么，如果對于“重建”聚集索引呢？這取決于SQL Server的版本以及你是進(jìn)行rebuild索引亦或是改變索引。一個常見的誤區(qū)是對表進(jìn)行分區(qū)將會改變聚集索引鍵，但事實(shí)上不會。對于那些會引起非聚集索引重建的操作，請看如下列表:Indexes From Every Angle: What happens to non-clustered indexes when the table structure is changed?。

您可能感興趣的文章:

SQL Server誤區(qū)30日談第28天有關(guān)大容量事務(wù)日志恢復(fù)模式的誤區(qū)
SQL Server誤區(qū)30日談第27天使用BACKUP WITH CHECKSUM可以替代DBCC CheckDB
SQL Server誤區(qū)30日談第26天 SQL Server中存在真正的“事務(wù)嵌套”
SQL Server誤區(qū)30日談第25天有關(guān)填充因子的誤區(qū)
SQL Server誤區(qū)30日談第24天 26個有關(guān)還原(Restore)的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過重啟SQL Server來修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個完整備份來重新開始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會將已提交的事務(wù)寫入磁盤
SQL Server誤區(qū)30日談第14天清除日志后會將相關(guān)的LSN填零初始化
SQL Server誤區(qū)30日談第13天在SQL Server 2000兼容模式下不能使用DMV
SQL Server誤區(qū)30日談第12天 TempDB的文件數(shù)和需要和CPU數(shù)目保持一致
SQL Server誤區(qū)30日談第11天鏡像在檢測到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫文件收縮不會影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個實(shí)例多個鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個誤區(qū)
SQL Server誤區(qū)30日談第5天 AWE在64位SQL SERVER中必須開啟
SQL Server誤區(qū)30日談第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
SQL Server誤區(qū)30日談第3天即時文件初始化特性可以在SQL Server中開啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
SQL Server誤區(qū)30日談第30天有關(guān)備份的30個誤區(qū)

標(biāo)簽：仙桃衡水黃山銅川崇左湖南湘潭蘭州

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)》，本文關(guān)鍵詞；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題，煩請?zhí)峁┫嚓P(guān)信息告之我們，我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無關(guān)。

佳木斯湛栽影视文化发展公司

SQL Server誤區(qū)30日談 第29天 有關(guān)堆碎片的誤區(qū)

QQ咨詢

電話咨詢

SQL Server誤區(qū)30日談第29天有關(guān)堆碎片的誤區(qū)