將聚集索引添加到現有表可以提高性能嗎？

我有一個SQL 2005數據庫，我已經繼承了這個數據庫，在過去的15年中，這個數據庫已經增長到大約1700萬條記錄，現在速度非常緩慢。將聚集索引添加到現有表可以提高性能嗎？

表佈局看起來大約是這樣的：

id_column = nvarchar(20),indexed, not unique 
column2 = nvarchar(20), indexed, not unique 
column3 = nvarchar(10), indexed, not unique 
column4 = nvarchar(10), indexed, not unique 
column5 = numeric(8,0), indexed, not unique 
column6 = numeric(8,0), indexed, not unique 
column7 = nvarchar(20), indexed, not unique 
column8 = nvarchar(10), indexed, not unique

（約5個欄，看起來幾乎相同，沒有索引）

的「ID」字段是在輸入值最終用戶的前端應用程序。

沒有定義的主鍵，並沒有列，其可以被組合以使一個唯一的行（除非所有列進行組合）。該表實際上是另一個表的「詳細信息」表，但不存在確保參照完整性的約束條件。

每列大量使用在「其中」條款的疑問，這就是爲什麼我認爲有每一個索引，或者是一個絕望的嘗試另一個DBA加快速度。

說了這麼多，我的問題是：能增加一個聚集索引做我任何好處在這一點？

如果我添加了聚集索引，我相信它會成爲一個新列，即，標識列？基本上，這是否值得麻煩？

欣賞任何建議。

來源

2014-12-27 Mark

可能屬於http://dba.stackexchange.com – 2014-12-27 15:28:59

你有什麼執行查詢的任何統計數據，也就是，其中列有最重要的？我試圖減少索引的數量，並使用包含在那些剩下的列來定位最頻繁的行標識符。 – tvanfosson 2014-12-27 15:36:01

我會說如果有推理需要它，只能添加聚集索引。所以問這些問題;

數據的順序是否有意義？

數據插入的方式是否有順序值？

我需要使用此功能，需要它有一個聚集索引，如全文索引？

如果這些問題的答案都是「否」，那麼聚合索引可能不會對優秀的非聚集索引策略提供任何其他幫助。相反，您可能需要考慮更新統計信息的方式和時間，刷新索引時以及篩選索引是否適合您的情況。以表格爲例，很難說，但是可能進一步規範化表格並使用數字鍵代替nvarchar是有意義的。

http://www.mssqltips.com/sqlservertip/3041/when-sql-server-nonclustered-indexes-are-faster-than-clustered-indexes/ 該文章是非聚集索引更合理的一個很好的例子。

來源

2014-12-27 16:25:32

我會建議增加一個聚集索引，即使它是一個標識列3個原因：

假設您現有的查詢必須通過整個表每次去，一個clustered index scan is still faster than a table scan。
該表是一個孩子一些其他的表。通過一些額外的工作，您可以使用新的child_id與父表進行聯合。這使得聚簇索引查找成爲可能，這在某些情況下比掃描要快得多。
取決於他們是如何設置的，現有的指標可能不會很好。我遇到了一些可怕的索引，每個索引都包含1列，或者索引不包含適當的列，導致代價高昂的密鑰查找操作。 Check your index stats看看他們是否被使用。

來源

2014-12-27 21:56:57

將聚集索引添加到現有表可以提高性能嗎？

回答

相關問題