久久狠狠色狠狠色综合,国产女同无遮挡互慰高潮,精品国产亚洲AⅤ麻豆

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

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

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

     對(duì)堆建聚集索引再DROP在我看來(lái)是除了收縮數(shù)據(jù)庫(kù)之外最2的事了。
     如果你通過(guò)sys.dm_db_index_physical_stats(或是老版本的DBCC SHOWCONTIG)看到堆上有碎片，絕對(duì)不要通過(guò)建立聚集索引再刪除聚集索引來(lái)整理堆碎片。好的做法應(yīng)該是建立聚集索引之后不再刪除，已經(jīng)有非常多的資料闡述如何選擇一個(gè)理想的聚集索引鍵--窄，很少變動(dòng)，唯一，自增。Kimberly有一篇文章對(duì)此做了一個(gè)總結(jié):Ever-increasing clustering key - the Clustered Index Debate..........again!(注意，是基于SQL Server 2005版本),對(duì)此我也有一個(gè)例子：An example of a nasty cluster key。
     你也可以在SQL Server 2008中通過(guò)ALTER TABLE ... REBUILD來(lái)清除堆碎片，但這個(gè)做法和建立聚集索引后再刪除同樣邪惡。
     如果你想問(wèn)為什么我對(duì)此甚有成見(jiàn)？好吧，那我解釋一下：非聚集索引中每一行都會(huì)指向一個(gè)RID或是聚集索引鍵的鏈接（詳情請(qǐng)看：What Happens if I Drop a Clustered Index?）,這個(gè)鏈接會(huì)以下面兩種方式之一出現(xiàn)：

如果非聚集索引所在的表是堆，那么這個(gè)鏈接就是一個(gè)RID。
如果非聚集索引所在的表是聚集索引，那么這個(gè)鏈接就是聚集索引鍵。
    如果你希望對(duì)此有更多了解，請(qǐng)看文章底部的鏈接。
    因此不難看出，如果你希望將堆變?yōu)榫奂饕?，那么非聚集索引的所有RID就失效了，因此所有的非聚集索引都需要被重建。同樣，如果刪除聚集索引鍵，那么所有非聚集索引上存儲(chǔ)的聚集索引鍵都會(huì)失效，因此也需要重建所有的非聚集索引。
    簡(jiǎn)單點(diǎn)說(shuō)，如果你建立再刪除聚集索引后，所有的非聚集索引都會(huì)被重建兩次。
   如果你使用SQL Server 2008的ALTER TABLE ... REBUILD來(lái)整理堆碎片，那么同樣也需要重建所有的非聚集索引，因?yàn)樗械腞ID都會(huì)變動(dòng)。
    那么，如果對(duì)于“重建”聚集索引呢？這取決于SQL Server的版本以及你是進(jìn)行rebuild索引亦或是改變索引。一個(gè)常見(jiàn)的誤區(qū)是對(duì)表進(jìn)行分區(qū)將會(huì)改變聚集索引鍵，但事實(shí)上不會(huì)。對(duì)于那些會(huì)引起非聚集索引重建的操作，請(qǐng)看如下列表: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個(gè)有關(guān)還原(Restore)的誤區(qū)
SQL Server誤區(qū)30日談第23天有關(guān)鎖升級(jí)的誤區(qū)
SQL Server誤區(qū)30日談第22天資源調(diào)控器可以調(diào)控IO
SQL Server誤區(qū)30日談第21天數(shù)據(jù)損壞可以通過(guò)重啟SQL Server來(lái)修復(fù)
SQL Server誤區(qū)30日談第20天破壞日志備份鏈之后，需要一個(gè)完整備份來(lái)重新開(kāi)始日志鏈
SQL Server誤區(qū)30日談第19天 Truncate表的操作不會(huì)被記錄到日志
SQL Server誤區(qū)30日談第18天有關(guān)FileStream的存儲(chǔ)，垃圾回收以及其它
SQL Server誤區(qū)30日談第17天有關(guān)頁(yè)校驗(yàn)和的誤區(qū)
SQL Server誤區(qū)30日談第16天數(shù)據(jù)的損壞和修復(fù)
SQL Server誤區(qū)30日談第15天 CheckPoint只會(huì)將已提交的事務(wù)寫(xiě)入磁盤(pán)
SQL Server誤區(qū)30日談第14天清除日志后會(huì)將相關(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天鏡像在檢測(cè)到故障后瞬間就能故障轉(zhuǎn)移
SQL Server誤區(qū)30日談第10天數(shù)據(jù)庫(kù)鏡像在故障發(fā)生后馬上就能發(fā)現(xiàn)
SQL Server誤區(qū)30日談第9天數(shù)據(jù)庫(kù)文件收縮不會(huì)影響性能
SQL Server誤區(qū)30日談第8天有關(guān)對(duì)索引進(jìn)行在線操作的誤區(qū)
SQL Server誤區(qū)30日談第7天一個(gè)實(shí)例多個(gè)鏡像和日志傳送延遲
SQL Server誤區(qū)30日談第6天有關(guān)NULL位圖的三個(gè)誤區(qū)
SQL Server誤區(qū)30日談第5天 AWE在64位SQL SERVER中必須開(kāi)啟
SQL Server誤區(qū)30日談第4天 DDL觸發(fā)器就是INSTEAD OF觸發(fā)器
SQL Server誤區(qū)30日談第3天即時(shí)文件初始化特性可以在SQL Server中開(kāi)啟和關(guān)閉
SQL Server誤區(qū)30日談第2天 DBCC CHECKDB會(huì)導(dǎo)致阻塞
SQL Server誤區(qū)30日談第1天正在運(yùn)行的事務(wù)在服務(wù)器故障轉(zhuǎn)移后繼續(xù)執(zhí)行
SQL Server誤區(qū)30日談第30天有關(guān)備份的30個(gè)誤區(qū)

標(biāo)簽：重慶貴州拉薩江蘇昭通呼和浩特上海新鄉(xiāng)

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