轉載：

http://www.cnblogs.com/flashicp/archive/2007/05/08/739245.html

?

建立非聚集索引(vid不是主鍵)

create?index?idx_test_vid?on?test(vid)? select COUNT(*) from Test

?

采用聚集索引

select?COUNT(*)?? from?test?with(index?(pk_test_id))?

?

?

刪除主鍵，也就刪除了聚集索引

alter table test drop constraint pk_test_id

?

刪除非聚集索引

drop index idx_test_vid on test

?

建議：

1、不是只要是索引都能提高性能，而是適當的時候適當的索引可適當地提高性能。什么時候需要建索引主要依據I/O輸出信息和查詢執行計劃具體分析。2、如何讓引擎充分使用索引一些建議 2.1 對于長字符串，比如VARCHAR(80)這種類型的索引要比更為緊湊數據類型的索引大很多。同樣地，你也不太可能對長字符串列進行全匹配查找。2.2 建立索引?對查詢進行優化，應盡量避免全表掃描，首先應考慮在?where?及?order?by?涉及的列上建立索引。?2.3 應盡量避免在?where?子句中對字段進行?null?值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：? select?id?from?t?where?num?is?null? 可以在num上設置默認值0，確保表中num列沒有null值，然后這樣查詢：? select?id?from?t?where?num=0?2.4 應盡量避免在?where?子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。?2.5 如果在?where?子句中使用參數，也會導致全表掃描。 因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：?select?id?from?t?where?num=@num? 可以改為強制查詢使用索引：?select?id?from?t?with(index(索引名))?where?num=@num2.6 應盡量避免在?where?子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：? select?id?from?t?where?num/2=100? 應改為:?select?id?from?t?where?num=100*2?2.7 應盡量避免在where子句中對字段進行函數（內置函數）操作， 這將導致引擎放棄使用索引而進行全表掃描。如：? select?id?from?t?where?substring(name,1,3)='abc'--name以abc開頭的id? select?id?from?t?where?datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id? 應改為:? select?id?from?t?where?name?like?'abc%'? select?id?from?t?where?createdate>='2005-11-30'?and?createdate<'2005-12-1'?2.8 不要在?where?子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。?2.9在使用索引字段作為條件時，如果該索引是復合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統使用該索引，否則該索引將不會被使用，并且應盡可能的讓字段順序與索引順序相一致。?2.10 不要寫一些沒有意義的查詢，如需要生成一個空表結構：? select?col1,col2?into?#t?from?t?where?1=0? 這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：? create?table?#t(...)?2.11 很多時候用?exists?代替?in?是一個好的選擇：? select?num?from?a?where?num?in(select?num?from?b)? 用下面的語句替換：? select?num?from?a?where?exists(select?1?from?b?where?num=a.num)?2.12 并不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引（除非是位圖索引），如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。?2.13 索引并不是越多越好，索引固然可以提高相應的?select?的效率，但同時也降低了?insert?及?update?的效率，因為?insert?或?update?時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。?2.14 應盡可能的避免更新?clustered?索引數據列，因為?clustered?索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新?clustered?索引數據列，那么需要考慮是否應將該索引建為?clustered?索引。?2.15 盡量使用數字型字段，若只含數值信息的字段盡量不要設計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數字型而言只需要比較一次就夠了。?2.16 盡可能的使用?varchar/nvarchar?代替?char/nchar，最好用varchar2（自變長度）?，因為首先變長字段存儲空間小，可以節省存儲空間，其次對于查詢來說，在一個相對較小的字段內搜索效率顯然要高些。?2.17 任何地方都不要使用?select?*?from?t?，用具體的字段列表代替“*”，不要返回用不到的任何字段。

?

總結

以上是生活随笔為你收集整理的SQLServer------聚集索引和非聚集索引的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。