聚簇索引

Question

這是真的，更新SQL查詢由於聚簇索引而變慢??????

Answer 1

定義緩着，當然聚集索引總是比一個非聚集索引慢...

Answer 2

你最好說'慢'而不是'慢'。當數據寫入聚簇索引時，數據並不會放在表格的最後，數據需要被嵌入才能適應，就像在一大堆字母表中添加一張CD一樣CD要比把它放在頂部慢很多。

Answer 3

插入和更新是慢由於聚簇索引（尤其是在巨大的表） - 但選擇方式更快。

使得指數非聚集通常會提高插入和更新性能保持性能的選擇（選擇往往不太高性能與聚集索引，但愛是妥協相比，非聚集索引）。

Answer 4

聚集索引指示表的物理存儲方式在磁盤上，因此更新表具有聚簇索引可能要求移動表格的重要部分以爲新記錄騰出空間，這很慢。

您可以通過爲索引設置適當的填充因子來緩解該問題。當你向中間添加記錄時，你不得不重新整理桌面;通常只有幾頁。 Fillfactor在創建新頁面之前確定每個頁面填充了多少，以及爲新插入留出多少空間作爲擺動空間。索引上較低的填充因子會爲新記錄留下更多空間，因此平均需要更快的插入時間，代價是更多的磁盤空間和更多頁面，因此讀取速度更慢。但是如果你做的比閱讀更多的更新，它可能是值得的。

Answer 5

如果你根本沒有任何聚簇索引，那麼你所擁有的就是一個「堆」。你也有一堆麻煩，因爲你的表中數據的順序是隨機的 - 從表中選擇數據將是slow。如果你做的更多INSERT s可能比你的SELECT s好，但通常情況並非如此。

無論是聚簇索引，使INSERT小號慢或不取決於：

• 表的填充因子（即是否有數據足夠的差距，以允許插入新的數據，而移動的一切周圍）。

• 選擇哪些列作爲羣集密鑰。

如果您使用標識列作爲羣集密鑰，那麼您可能會發現插入性能非常好，因爲新條目總是添加在最後。如果使用當前日期（當然也在不斷增加），則可能也適用於日期時間列。

您需要保持羣集密鑰的大小很小，因爲這是存儲在每個其他索引中的數據的索引。例如，如果您的羣集密鑰由3個整數和一個日期時間組成，那麼除了您試圖建立索引的所有其他索引之外，其他所有索引中的每個條目都將包含所有數據。出於這個原因，標識列實際上是羣集密鑰的一個很好的選擇，因爲它很好，因爲它很不錯。

任何情況下的完美集羣密鑰只能通過大量思考和大量測試（具有實際大數據集）進行選擇。擁有良好的羣集密鑰可以使性能與SELECT的性能相差甚遠，這通常會超過INSERT性能的任何降級。