總是在數據庫表上定義聚簇索引是個好主意嗎？

我目前正在研究一個廣泛使用的.NET CMS系統的性能問題，並且有一個特定的表，其中有大約5,000,000條記錄，這是造成這些問題的根本原因，只是查詢此表的內容最多需要2分鐘在我的本地開發環境。總是在數據庫表上定義聚簇索引是個好主意嗎？

查看該表的模式，我注意到只有一個唯一的非聚簇索引並且沒有聚簇索引。

表&指數定義如下

CREATE TABLE [dbo].[MyTable](
    [Id] [uniqueidentifier] NOT NULL, 
    [ItemId] [uniqueidentifier] NOT NULL, 
    [Language] [nvarchar](50) NOT NULL, 
    [FieldId] [uniqueidentifier] NOT NULL, 
    [Value] [nvarchar](max) NOT NULL, 
    [Created] [datetime] NOT NULL, 
    [Updated] [datetime] NOT NULL 
) 


CREATE UNIQUE NONCLUSTERED INDEX [IX_Unique] ON [dbo].[MyTable] 
(
    [ItemId] ASC, 
    [Language] ASC, 
    [FieldId] ASC 
)

有沒有人對這個表周圍指標的任何建議，以提高查詢性能，特別是它總體上是好的做法，總是在一個表上定義一個聚集索引？

謝謝

來源

2011-07-25 nickc

爲了表明其指標會有所幫助，我們需要知道你是如何訪問表。你對它執行的查詢是什麼？ – hatchet

對於任何「正常」數據表 - 是的，我總是會推薦一個**好**聚簇索引（在一個狹窄的，穩定的，獨特的，最好不斷增加的列）。這可能不適用於臨時表格，用於例如批量插入等 - 但其他任何事情都從一個好的聚集索引中受益，是的 –

我不認爲你可以說'總是'好或壞。

你有沒有執行的查詢解釋計劃？

如果該查詢的where子句不使用索引列，那麼附加索引可能會有很大幫助。

來源

2011-07-25 13:08:15 Randy

我同意Randy的看法，它取決於表格主要用於什麼。 This是關於「聚集索引辯論」的偉大文章。

有太多在這裏總結一下，但一般INSERT是一個聚集索引總是更快，UPDATE是通常更快，SELECT更依賴於其他因素，如具有可覆蓋非聚集索引。

來源

2011-07-25 13:12:08 Yuck

聚簇索引對索引鍵上的表進行排序，並按照該順序物理存儲它。這就是爲什麼在任何表上只能定義1個聚集索引的原因。爲獲得最佳結果，建議在唯一值上加上聚集索引。

如果有多種查詢訪問您的表（使用不在聚集索引中的列），那麼在這些查詢過濾的列上添加更多的非聚簇索引會更好。

檢查this msdn link的詳細信息，聚集索引

來源

2011-07-26 10:31:38 Mulki

總是在數據庫表上定義聚簇索引是個好主意嗎？

回答

相關問題