前言： 本文對這篇博客Clustered Tables vs Heap Tables 的翻譯, 如有翻譯不對或不好的地方，敬請指出，大家一起學習進步。

問題描述

???? 創(chuàng)建一個新表時，一個非常重要的設計原則就是創(chuàng)建還是不創(chuàng)建聚集索引的決定。沒有聚集索引的表被稱為堆，擁有聚集索引的表叫聚集索引表。 聚集索引表比堆表擁有一些好處（優(yōu)勢），比如聚集索引表是基于聚集索引鍵順序存儲的，正因為如此，所以通過聚集索引可以快速查找某一行；可以通過重建聚集索引重新組織數(shù)據(jù)。當你對表進行INSERT、UPDATE、DELETE等操作時可能會使物理數(shù)據(jù)變得碎片化，這種碎片化可能會導致你浪費大量數(shù)據(jù)庫存儲空間，因為本來可以存儲在一頁的數(shù)據(jù)，需要存儲在多個數(shù)據(jù)頁上（Pages）,那么，我們該怎么做呢？

解決方案

? 我們要解決的首要問題是發(fā)生在數(shù)據(jù)庫正常活動中的碎片。你的表是否擁有聚集索引 將決定您是否可以在數(shù)據(jù)庫物理層面很容易的解決碎片化問題。因為堆或聚集索引決定你表數(shù)據(jù)的物理存儲，每個表要么擁有一個聚集索引或沒有一個聚集索引，所以每個表要么是一個堆或聚集索引表。

讓我們來看看一個堆表和聚集索引表之間的差異：

HEAP

??? 數(shù)據(jù)存儲沒有任何特定的順序。

??? 不能快速的找到特定數(shù)據(jù)，除非也有非聚集索引。

??? 數(shù)據(jù)頁之間沒有指針關(guān)聯(lián)，所以順序訪問需要重新返回到索引分配映射（IAM）頁

??? 既然沒有聚集索引，所以不用額外的時間去維護聚集索引。

??? 既然沒有聚集索引，所以不用額外的空間去存儲聚集索引樹。

??? 堆表的索引在sys.indexes目錄視圖的記錄的index_id字段值為0

Clustered Table

???? 數(shù)據(jù)存儲基于聚集索引鍵順序存儲。

???? 如果查詢時使用聚集索引列，數(shù)據(jù)可以基于聚集索引鍵快速檢索到。

???? 數(shù)據(jù)頁之間有指針鏈接，可以更快速的順序訪問。

???? 當INSERT、UPDATE、DELETE操作時，需要額外的時間維護聚集索引。

???? 需要額外的空間存儲聚集索引樹。

???? 聚集索引表在sys.indexes目錄視圖的記錄的index_id值為1.

所以，基于以上你可以看到有一個表是否具有聚簇索引將決定表的一些根本性的不同之處。

碎片化問題

所有的表都會發(fā)生的一個問題就是碎片化的問題。根據(jù)不同的操作，比如刪除，插入和更新，您的堆表和聚集索引表將會變得越來越碎片化。碎片化很多時候取決于INSERT、UPDATE、DELTE這類操作，以及用作聚集索引的鍵。

? 如果您的堆表只有INSERT操作，你的表不會變得碎片化，因為只有新的數(shù)據(jù)寫入。

? 如果您的聚集索引鍵是連續(xù)的，比如一個自增字段。并且對該表你只有INSERT操作，這同樣也不會變得碎片化，因為新的數(shù)據(jù)總是寫在聚簇索引的后面。

? 但是，如果你的表是一個堆或聚集表，并有大量的插入，更新和刪除操作，數(shù)據(jù)頁碎片化可能會變得越來越嚴重。這不僅會導致浪費額外的空間，而且需要讀取額外的數(shù)據(jù)頁來滿足查詢。?

? 當一個表在堆上創(chuàng)建，SQL Server不會強迫在那個新數(shù)據(jù)頁（New Page）寫入數(shù)據(jù)。每當新的數(shù)據(jù)寫入時，該數(shù)據(jù)總是寫在表的末端，或者分配給該表中的下一個可用的頁面上。當數(shù)據(jù)被刪除時，數(shù)據(jù)頁上的空間釋放出來，但它不重復使用，因為新數(shù)據(jù)總是寫入到下一個可用的頁面。

? 具有聚簇索引，根據(jù)索引鍵，新的記錄可能會被寫入到現(xiàn)有的頁面，這些頁面可能存在的空閑的空間或者有可能需要分割成多個頁面的頁面。以便插入新的數(shù)據(jù)。刪除時會發(fā)生同樣的問題時，與一個堆對比，但是這些空閑間可以再次使用，如果數(shù)據(jù)需要插入到具有可用空間的現(xiàn)有頁面中的一個。

? 所以，基于以上敘述 ，你的堆表可能變得比你的聚集表更加支離破碎。

查看碎片化
要確定您的聚集索引表或堆表是否碎片化，你要么通過運行DBCC SHOWCONTIG（SQL SEREVER 2000或SQL SEREVER 2005）查看，或使用新的DMVsys.dm_db_index_physical_stats（SQL SERVER 2005 以及以后版本）。這些命令能讓你查看表中可能存在的碎片化問題。如需更多相關(guān)信息，看看以前的這篇文章提示：SQL Server 2000 to 2005 Crosswalk - Index Rebuilds.

解決碎片化

聚集索引表

??? 解決聚集索引的碎片化可以很容易地通過重建或重新組織你的聚集索引來完成。這表現(xiàn)在這之前的提示： SQL Server 2000 to 2005 Crosswalk - Index Rebuilds

堆表

對于堆表來說，這個不太容易的。您可以采取以下不同的方法來解決碎片問題：

對堆表創(chuàng)建一個聚集索引

創(chuàng)建一個新的堆表，并根據(jù)某種順序?qū)⑴f表中的數(shù)據(jù)插入到新表

導出數(shù)據(jù)，截斷表并導入數(shù)據(jù)返回到表

附加信息

??? 當你通過企業(yè)管理器或Management Studio創(chuàng)建一個新表并在新表中指定一個主鍵，管理工具會自動為其創(chuàng)建一個聚集索引，但可以被重寫。當通過腳本創(chuàng)建一個新表時，你需要明確指定創(chuàng)建聚集索引。所以，正是由于主鍵關(guān)系，你大部分的表將會擁有一個聚集索引，但如果創(chuàng)建表時，你不指定一個主鍵或建立聚集索引，該表的數(shù)據(jù)將被存儲為一個堆。

?

下一步

?

?? 維持表和索引的碎片化在控制范圍內(nèi)是保持數(shù)據(jù)庫最佳性能的一個關(guān)鍵過程?，F(xiàn)在你可以明白一個堆與聚集索引表在解決碎片化上的不同，看看你的表結(jié)構(gòu)，看看你需要解決這些問題。

?? 即使對所有表一個星期做一次索引重建，你的堆表是永遠不會解決瑣碎化問題的，所以你需要想出另一種策略來處理堆表的碎片問題。

?? 一起來看看這些相關(guān)技巧：

????? SQL Server 2000 to 2005 Crosswalk - Database Fragmentation.

????? SQL Server 2000 to 2005 Crosswalk - Index Rebuilds.

? 基于上述論證，似乎所有的表都應該有一個聚集索引。在大多數(shù)情況下是這樣，但也可能由于某種原因，你不希望有一個聚集索引。一個原因可能是該表只有INSERT操作，例如一個日志記錄的表。但是毫無疑問，有聚集索引一定好過沒有聚集索引

總結(jié)

以上是生活随笔為你收集整理的[翻译] 聚集索引表 VS 堆表的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。