SQL Server 索引結構及其使用(一)--深入淺出理解索引結構第2/4頁
更新時間:2009年04月09日 00:35:22 作者:
深入淺出理解索引結構
三、結合實際,談索引使用的誤區(qū)
理論的目的是應用。雖然我們剛才列出了何時應使用聚集索引或非聚集索引,但在實踐中以上規(guī)則卻很容易被忽視或不能根據(jù)實際情況進行綜合分析。下面我們將根據(jù)在實踐中遇到的實際問題來談一下索引使用的誤區(qū),以便于大家掌握索引建立的方法。
1、主鍵就是聚集索引
這種想法筆者認為是極端錯誤的,是對聚集索引的一種浪費。雖然SQL SERVER默認是在主鍵上建立聚集索引的。
通常,我們會在每個表中都建立一個ID列,以區(qū)分每條數(shù)據(jù),并且這個ID列是自動增大的,步長一般為1。我們的這個辦公自動化的實例中的列Gid就是如此。此時,如果我們將這個列設為主鍵,SQL SERVER會將此列默認為聚集索引。這樣做有好處,就是可以讓您的數(shù)據(jù)在數(shù)據(jù)庫中按照ID進行物理排序,但筆者認為這樣做意義不大。
顯而易見,聚集索引的優(yōu)勢是很明顯的,而每個表中只能有一個聚集索引的規(guī)則,這使得聚集索引變得更加珍貴。
從我們前面談到的聚集索引的定義我們可以看出,使用聚集索引的最大好處就是能夠根據(jù)查詢要求,迅速縮小查詢范圍,避免全表掃描。在實際應用中,因為ID號是自動生成的,我們并不知道每條記錄的ID號,所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次,讓每個ID號都不同的字段作為聚集索引也不符合“大數(shù)目的不同值情況下不應建立聚合索引”規(guī)則;當然,這種情況只是針對用戶經(jīng)常修改記錄內(nèi)容,特別是索引項的時候會負作用,但對于查詢速度并沒有影響。
在辦公自動化系統(tǒng)中,無論是系統(tǒng)首頁顯示的需要用戶簽收的文件、會議還是用戶進行文件查詢等任何情況下進行數(shù)據(jù)查詢都離不開字段的是“日期”還有用戶本身的“用戶名”。
通常,辦公自動化的首頁會顯示每個用戶尚未簽收的文件或會議。雖然我們的where語句可以僅僅限制當前用戶尚未簽收的情況,但如果您的系統(tǒng)已建立了很長時間,并且數(shù)據(jù)量很大,那么,每次每個用戶打開首頁的時候都進行一次全表掃描,這樣做意義是不大的,絕大多數(shù)的用戶1個月前的文件都已經(jīng)瀏覽過了,這樣做只能徒增數(shù)據(jù)庫的開銷而已。事實上,我們完全可以讓用戶打開系統(tǒng)首頁時,數(shù)據(jù)庫僅僅查詢這個用戶近3個月來未閱覽的文件,通過“日期”這個字段來限制表掃描,提高查詢速度。如果您的辦公自動化系統(tǒng)已經(jīng)建立的2年,那么您的首頁顯示速度理論上將是原來速度8倍,甚至更快。
相關文章
SQL Server 公用表表達式(CTE)實現(xiàn)遞歸的方法
這篇文章主要介紹了SQL Server 公用表表達式(CTE)實現(xiàn)遞歸的方法,需要的朋友可以參考下2017-05-05NetBeans連接SQL server數(shù)據(jù)庫教程
這篇文章主要介紹了NetBeans連接SQL server數(shù)據(jù)庫教程,本文通過圖文并茂的形式給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-06-06Sql語句與存儲過程查詢數(shù)據(jù)的性能測試實現(xiàn)代碼
Sql語句 存儲過程查 性能測試對比代碼。2009-04-04SQL Server 數(shù)據(jù)庫索引其索引的小技巧
關于索引的常識:影響到數(shù)據(jù)庫性能的最大因素就是索引。由于該問題的復雜性,我只可能簡單的談談這個問題,不過關于這方面的問題,目前有好幾本不錯的書籍可供你參閱。我在這里只討論兩種SQL Server索引,即clustered索引和nonclustered索引2012-06-06