何時應(yīng)使用聚集索引或非聚集索引，但在實踐中以上規(guī)則卻很容易被忽視或不能根據(jù)實際情況進(jìn)行綜合分析。下面我們將根據(jù)在實踐中遇到的實際問題來談一下索引使用的誤區(qū)，以便于大家掌握索引建立的方法。

　　1、主鍵就是聚集索引

　　這種想法筆者認(rèn)為是極端錯誤的，是對聚集索引的一種浪費。雖然SQL SERVER默認(rèn)是在主鍵上建立聚集索引的。

　　通常，我們會在每個表中都建立一個ID列，以區(qū)分每條數(shù)據(jù)，并且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的實例中的列Gid就是如此。此時，如果我們將這個列設(shè)為主鍵，SQL SERVER會將此列默認(rèn)為聚集索引。這樣做有好處，就是可以讓您的數(shù)據(jù)在數(shù)據(jù)庫中按照ID進(jìn)行物理排序，但筆者認(rèn)為這樣做意義不大。

　　顯而易見，聚集索引的優(yōu)勢是很明顯的，而每個表中只能有一個聚集索引的規(guī)則，這使得聚集索引變得更加珍貴。

　　從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大之一好處就是能夠根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃描。在實際應(yīng)用中，因為ID號是自動生成的，我們并不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進(jìn)行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個ID號都不同的字段作為聚集索引也不符合“大數(shù)目的不同值情況下不應(yīng)建立聚合索引”規(guī)則;當(dāng)然，這種情況只是針對用戶經(jīng)常修改記錄內(nèi)容，特別是索引項的時候會負(fù)作用，但對于查詢速度并沒有影響。

　　在辦公自動化系統(tǒng)中，無論是系統(tǒng)首頁顯示的需要用戶簽收的文件、會議還是用戶進(jìn)行文件查詢等任何情況下進(jìn)行數(shù)據(jù)查詢都離不開字段的是“日期”還有用戶本身的“用戶名”。

　　通常，辦公自動化的首頁會顯示每個用戶尚未簽收的文件或會議。雖然我們的where語句可以僅僅限制當(dāng)前用戶尚未簽收的情況，但如果您的系統(tǒng)已建立了很長時間，并且數(shù)據(jù)量很大，那么，每次每個用戶打開首頁的時候都進(jìn)行一次全表掃描，這樣做意義是不大的，絕大多數(shù)的用戶1個月前的文件都已經(jīng)瀏覽過了，這樣做只能徒增數(shù)據(jù)庫的開銷而已。事實上，我們完全可以讓用戶打開系統(tǒng)首頁時，數(shù)據(jù)庫僅僅查詢這個用戶近3個月來未閱覽的文件，通過“日期”這個字段來限制表掃描，提高查詢速度。如果您的辦公自動化系統(tǒng)已經(jīng)建立的2年，那么您的首頁顯示速度理論上將是原來速度8倍，甚至更快。

　　在這里之所以提到“ 理論上”三字，是因為如果您的聚集索引還是盲目地建在ID這個主鍵上時，您的查詢速度是沒有這么高的，即使您在“日期”這個字段上建立的索引(非聚合索引)。下面我們就來看一下在1000萬條數(shù)據(jù)量的情況下各種查詢的速度表現(xiàn)(3個月內(nèi)的數(shù)據(jù)為25萬條)：

　　(1)僅在主鍵上建立聚集索引，并且不劃分時間段：

　　Select gid,fariqi,neibuyonghu,title from tgongwen

　　用時：128470毫秒(即：128秒)

　　(2)在主鍵上建立聚集索引，在fariq上建立非聚集索引：