程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> SQL Server 索引結構及其使用(四)

SQL Server 索引結構及其使用(四)

編輯:關於SqlServer


  聚集索引的重要性和如何選擇聚集索引

  在上一節的標題中,筆者寫的是:實現小數據量和海量數據的通用分頁顯示存儲過程。這是因為在將本存儲過程應用於“辦公自動化”系統的實踐中時,筆者發現這第三種存儲過程在小數據量的情況下,有如下現象:

  1、分頁速度一般維持在1秒和3秒之間。

  2、在查詢最後一頁時,速度一般為5秒至8秒,哪怕分頁總數只有3頁或30萬頁。

  雖然在超大容量情況下,這個分頁的實現過程是很快的,但在分前幾頁時,這個1-3秒的速度比起第一種甚至沒有經過優化的分頁方法速度還要慢,借用戶的話說就是“還沒有Access數據庫速度快”,這個認識足以導致用戶放棄使用您開發的系統。

  筆者就此分析了一下,原來產生這種現象的症結是如此的簡單,但又如此的重要:排序的字段不是聚集索引!

  本篇文章的題目是:“查詢優化及分頁算法方案”。筆者只所以把“查詢優化”和“分頁算法”這兩個聯系不是很大的論題放在一起,就是因為二者都需要一個非常重要的東西――聚集索引。
在前面的討論中我們已經提到了,聚集索引有兩個最大的優勢:

  1、以最快的速度縮小查詢范圍。

  2、以最快的速度進行字段排序。

  第1條多用在查詢優化時,而第2條多用在進行分頁時的數據排序。

  而聚集索引在每個表內又只能建立一個,這使得聚集索引顯得更加的重要。聚集索引的挑選可以說是實現“查詢優化”和“高效分頁”的最關鍵因素。

  但要既使聚集索引列既符合查詢列的需要,又符合排序列的需要,這通常是一個矛盾。筆者前面“索引”的討論中,將fariqi,即用戶發文日期作為了聚集索引的起始列,日期的精確度為“日”。這種作法的優點,前面已經提到了,在進行劃時間段的快速查詢中,比用ID主鍵列有很大的優勢。

  但在分頁時,由於這個聚集索引列存在著重復記錄,所以無法使用max或min來最為分頁的參照物,進而無法實現更為高效的排序。而如果將ID主鍵列作為聚集索引,那麼聚集索引除了用以排序之外,沒有任何用處,實際上是浪費了聚集索引這個寶貴的資源。

  為解決這個矛盾,筆者後來又添加了一個日期列,其默認值為getdate()。用戶在寫入記錄時,這個列自動寫入當時的時間,時間精確到毫秒。即使這樣,為了避免可能性很小的重合,還要在此列上創建UNIQUE約束。將此日期列作為聚集索引列。

  有了這個時間型聚集索引列之後,用戶就既可以用這個列查找用戶在插入數據時的某個時間段的查詢,又可以作為唯一列來實現max或min,成為分頁算法的參照物。

  經過這樣的優化,筆者發現,無論是大數據量的情況下還是小數據量的情況下,分頁速度一般都是幾十毫秒,甚至0毫秒。而用日期段縮小范圍的查詢速度比原來也沒有任何遲鈍。聚集索引是如此的重要和珍貴,所以筆者總結了一下,一定要將聚集索引建立在:

  1、您最頻繁使用的、用以縮小查詢范圍的字段上;

  2、您最頻繁使用的、需要排序的字段上。

  結束語

  本篇文章匯集了筆者近段在使用數據庫方面的心得,是在做“辦公自動化”系統時實踐經驗的積累。希望這篇文章不僅能夠給大家的工作帶來一定的幫助,也希望能讓大家能夠體會到分析問題的方法;最重要的是,希望這篇文章能夠拋磚引玉,掀起大家的學習和討論的興趣,以共同促進,共同為公安科技強警事業和金盾工程做出自己最大的努力。

  最後需要說明的是,在試驗中,我發現用戶在進行大數據量查詢的時候,對數據庫速度影響最大的不是內存大小,而是CPU。在我的P4 2.4機器上試驗的時候,查看“資源管理器”,CPU經常出現持續到100%的現象,而內存用量卻並沒有改變或者說沒有大的改變。即使在我們的HP ML 350 G3服務器上試驗時,CPU峰值也能達到90%,一般持續在70%左右。

  本文的試驗數據都是來自我們的HP ML 350服務器。服務器配置:雙Inter Xeon 超線程 CPU 2.4G,內存1G,操作系統Windows Server 2003 Enterprise Edition,數據庫SQL Server 2000 SP3

(完)

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved