集羣索引SQL Server

Question

我有一個Oracle背景，每個表使用「索引組織表」（IOT）在Oracle中聽起來不合理，我從來沒有看到過這種情況。在SQL Server中，我工作的每個數據庫在每個表上都有一個聚簇索引，這與IOT（概念上）相同。

這是爲什麼？在任何地方使用聚簇索引是否有任何理由？在我看來，只有少數情況下他們纔會好。

感謝

Answer 1

如果沒有聚簇索引，您的表被組織爲一個堆。這意味着插入的每一行都被添加到表格末尾的數據頁面中。同樣，當行更新時，如果更新的數據比以前更大，它們將移動到表的末尾的數據頁面。

當這是好事，沒有一個聚集索引

如果您有需要以最快的速度插入一個表格，但可以犧牲更新和讀取速度，那麼沒有一個聚集索引可以用於工作您。一個例子是如果你有一個被用作隊列的表，例如，大量的插入後來才被讀取並移動到不同的表中。

聚集索引

聚簇索引基於聚集索引中的列在表中組織數據。如果你把錯誤的東西聚集在一起，例如一個獨特的標識符，這可能會減慢速度（見下文）。

只要您的聚集索引是最常用於搜索的值，並且它是獨一無二的並且越來越多，您就可以從聚集索引中獲得驚人的性能優勢。例如，如果您有一個名爲USERS的表，您通常根據USER_ID查找用戶數據，則在USER_ID上進行聚類可以加快所有這些查找的性能。這簡單地減少了需要讀取以獲取數據的數據頁的數量。

如果聚簇索引中的鍵太多，這也會減慢速度。

聚簇索引的一般規則：

不聚集在任何varchar列上。

對INT IDENTITY列進行聚類通常是最好的。

關於您常用搜索的羣集。在UniqueIdentifiers

隨着指數uniqueidentifiers

聚類，他們是非常低效的，因爲沒有自然的排序順序。基於索引的b-tree結構，當使用uniqueidentifiers時，最終會產生極其分散的索引。重建或重組後，它們仍然非常分散。所以你最終會得到一個較慢的索引，由於存在碎片，最終會導致在內存和磁盤上非常龐大。同樣，在插入uniqueidentifier時，您更可能最終在索引上進行頁面拆分，從而減慢插入速度。通常，uniqueidentifiers對於索引是個壞消息。

摘要

我的建議是，每個表上應該有一個聚集索引，除非有很好的理由不要（即表作爲隊列功能）。

Answer 2

我們使用主鍵在關係數據庫和一般的關係，通過這些主鍵建立。大多數人習慣於將第一個字段命名爲TableID並將其作爲主鍵。當您在查詢中加入兩個或多個表時，如果使用聚簇索引，您將獲得最快的結果。

Answer 3

我不知道爲什麼大多數時候你更喜歡堆積聚集索引。使用集羣，您可以免費獲得您選擇的一個索引。大多數情況下，這是主鍵（無論如何，您可能要強制執行！）。

堆主要針對特殊情況。

Answer 4

聚集索引與索引組織表不完全相同。使用IOT，每個字段都必須參與IOT密鑰。 SQL Server上的聚集索引不必是唯一的，並且不必是主鍵。

集羣索引廣泛用於SQL Server，因爲幾乎總是有一些自然排序使常用查詢更高效。甲骨文的物聯網帶着更多的包袱，所以它們並沒有那麼有用，儘管它們可能更有用，然後他們通常被稱爲。

從歷史上看，真正舊版本的SQL Server pre 6.5或7.0 IIRC不支持行級鎖定，只能鎖定在表或頁級別。通常會使用聚簇索引來確保寫入分散在表的物理存儲周圍，以最大限度地減少對頁面鎖的爭用。但是，SQL Server 6在幾年前就已經得到支持，所以具有此問題的應用程序將僅限於罕見的遺留系統。