[zt] SQLSERVER索引的使用技巧

tolywang發表於2009-05-22
         之前做過一次試驗,當所建立的索引沒有在where條件中應用時,查詢結果需要40多分鐘;而建對索引時,不到30秒,很神奇吧,這就是索引的作用,他就像目錄一樣,可以輕鬆的找到你想要的資料,就像字典,如果沒有目錄,可想其查詢的難度。

在總結索引設計的原則時,我們有必要來闡述SQLSERVER中索引的四種型別:

1.聚集索引(Cluster Index)
聚集索引中索引儲存的值的順序和表中的資料的物理儲存順序是完全一致的。建立索引時,系統將對錶的物理資料頁中的資料按列進行排序,然後再重新儲存到磁碟上,即聚集索引與資料是混為一體的,它的葉節點中儲存的是實際的資料。特點如下:

  • 表的資料按照索引的資料順序排列;
  • 每個資料表只能建立一個聚集索引,並且會在第一個建立,往往會在主碼所在的列或者最常查詢的列上建立聚集索引;
  • 索引將佔用使用者資料庫的空間;
  • 適合範圍查詢。


建立聚集索引後,更新索引列資料,往往會導致表中物理記錄的儲存順序的變化,維護的代價會比較大,對於需要經常更新的列,不宜建立聚集索引。

2.非聚集索引(Non-Cluster Index)
非聚集索引儲存的資料順序一般和表的物理資料的儲存不同。儘管查詢速度慢一些,但是維護的代價小。而且表中最多可以建立249個非聚集索引以滿足多種查詢的需要。

3.惟一索引(Unique Index)
惟一索引是指索引儲存的值必須是惟一的,不允許兩行具有相同的索引值(包括NULL)。主碼索引時當然的惟一索引。

4.複合索引
複合索引是指利用表中的多個列值的組合來構建索引值。SQLServer 2000規定複合索引最多使用16個列的值進行組合,索引列值最大長度不能超過900位元組,而且這些列必須在同一個資料表中。

而合理的索引設計是要建立在對各種查詢的分析和預測上,我們可以按照如下原則建立索引,希望對軟體開發相關人員有所幫助:

  • 索引中的資料儘可能少,即窄索引更容易被選擇;
  • 聚集索引碼要被包含在表的所有的非聚集索引中,所以聚集索引碼要儘可能短;
  • 建立高選擇性的非聚集索引;
  • 頻繁請求的列上不能建立聚集索引,應該建立非聚集索引,並且要儘可能使值惟一;
  • 儘可能減少熱點資料。如果頻繁地對錶中的某些資料進行讀和寫,這些資料就是熱點資料,要想辦法將熱點資料分散;
  • 監控磁碟的資料流量。如果利用率太高,就要考慮索引列並在多個磁碟上分佈資料以減少I/O;
  • 在至少有一個索引的表中,應該有一個聚集索引。包括的不同值的個數有限,返回一定範圍內值的列,查詢時返回大量結果的列考慮建立聚集索引;
  • 分析經常使用的SQL語句的Where子句,得出經常取值的資料,考慮對這些資料列根據常見的查詢型別建立索引;
  • 主碼如果涉及多個資料列,要將顯著變化的資料列放在首位。如果資料列的變化程度相當,將經常訪問的資料列放在首位;
  • 有大量重複值、且經常有範圍查詢。如(between,>,=,<=)、order by、group by發生的列,可考慮建立聚集索引;
  • SQL查詢語句同時存取多列的資料,且每列都含有重複值,可以考慮建立覆蓋索引,覆蓋索引要儘量使關鍵查詢形成索引覆蓋,其前導列一定是使用最頻繁的列;
  • 索引值較短的索引具有比較高的效率,因為每個索引頁上能存放較多的索引行,而且索引的級別也比較少。所以,快取中能防止更多的索引列,這樣也減少了I/O操作;
  • 表上的索引過多會影響UPDATE、INSERT和DELETE的效能,因為所有的索引必須做響應的調整。另外,所有的分頁操作都被記錄在日誌中,這樣也會增加I/O操作;
  • 一般不對經常被更新的列建立聚集索引,這樣會引起整行的移動,嚴重影響效能;
  • 查詢很少或著資料很少的資料表一般不用建立索引;
  • 與ORDER BY或GROUP BY一起使用的列一般使用建立聚集索引。如果ORDER BY 命令中用到的列上有聚集索引,就不會生成1個臨時表,因為行已經排序。GROUP BY命令則一定產生1個臨時表;
  • 當有大量的行正在被插入表中時,要避免在本表一個自然增長(例如Identity列)的列上建立聚集索引。如果建立了聚集索引,那麼INSERT的效能就會大大降低,因為每個插入的行必須到表的最後一個資料頁面

 

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-600778/,如需轉載,請註明出處,否則將追究法律責任。

相關文章