集羣索引

SQL Server中的Insert/Update/Delete語句應使用哪種類型的索引（clustered/non clustrered）。我知道它會產生額外的開銷，但與非聚集索引相比，性能會更好嗎？還應該使用哪種索引用於SQL Server中的Select語句？集羣索引

來源

2010-04-23 Charu

你讀過這個問題：http://stackoverflow.com/questions/91688/what-are-the-differencespros-cons-between-clustered-and-non-clustered-indexes？ – 2010-04-23 20:47:36

我不太清楚你的意思是「應該用於插入/更新/刪除語句」，但在我看來，每個表都應該有一個聚集索引。聚集索引指定數據實際存儲的順序。如果未定義聚簇索引，則數據將被簡單地存儲在堆中。如果你沒有一個自然的列作爲你的聚集索引，你總是可以像這樣創建一個標識列作爲int或bigint。

CREATE TABLE [dbo].[demo](
[ID] [int] IDENTITY(1,1) NOT NULL, 
[FirstName] [nchar](10) NULL, 
[LastName] [nchar](10) NULL, 
[Job] [nchar](10) NULL, 
CONSTRAINT [PK_demo] PRIMARY KEY CLUSTERED 
(
[ID] ASC 
))

來源

2010-04-23 20:29:40 etoisarobot

不是100％肯定你期望聽到的東西 - 你永遠只能有一個表上的單一聚簇索引，默認情況下，每個表（除了極少數邊緣情況例外）應該有一個。所有的指數通常會幫助你的選擇最多，有些傾向於傷害插入，刪除和可能的更新（或很多，如果選擇不好）。

聚簇索引使得每個操作的表更快。是！它的確如此。有關背景信息，請參閱Kim Tripp出色的The Clustered Index Debate continues。她還提到她的主要標準，一個聚集索引：

窄
靜態（永遠不會改變）
獨特
如果有的話可能：不斷增加的

INT IDENTITY滿足這個完美 - GUID不。有關廣泛的背景信息，請參閱GUID's as Primary Key。

爲什麼縮小？因爲聚簇鍵被添加到同一個表上的每個非聚簇索引的每個索引頁（爲了能夠實際查找數據行，如果需要的話）。您不想在您的羣集密鑰中包含VARCHAR（200）....

爲什麼獨特？請參閱上文 - 集羣密鑰是SQL Server用來唯一地查找數據行的項目和機制。它必須是獨一無二的。如果您選擇一個非唯一集羣密鑰，SQL Server本身會爲您的密鑰添加一個4字節的唯一標識符。小心點！

下一個：非聚集索引。基本上有一條規則：引用另一個表的子表中的任何外鍵都應該被索引，這會加快JOIN和其他操作。此外，任何具有WHERE子句的查詢都是很好的候選者 - 挑選那些首先執行很多的查詢。在ORDER BY語句中，將索引放在WHERE子句中顯示的列上。

下一步：測量您的系統，檢查DMV（動態管理視圖）中關於未使用或缺失索引的提示，並一遍又一遍地調整系統。這是一個持續的過程，你永遠不會做！

警告的另一個詞：使用一整套索引，可以使任何SELECT查詢變得非常快速。但與此同時，必須更新涉及的所有索引的INSERT，UPDATE和DELETE可能會受到影響。如果你只有選擇 - 堅果！否則，這是一種精緻而微妙的平衡行爲。你可以隨時調整一個單一的查詢 - 但你的系統的其他部分可能會因此而受到影響。不要過度索引你的數據庫！放入一些好的指標，檢查並觀察系統的行爲，然後再添加一個或兩個：觀察整個系統性能如何受到影響。

來源

2010-04-23 20:31:51

+1好帖子。謝謝。 – Rahul 2011-11-08 14:22:24

回答

相關問題