【文章內容簡介】 處就是能夠根據查詢要求，迅速縮小查詢范圍，避免全表掃描。在實際應用中，因為ID號是自動生成的，我們并不知道每條記錄的ID號，所以我們很難在實踐中用ID號來進行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費。其次，讓每個ID號都不同的字段作為聚集索引也不符合“大數目的不同值情況下不應建立聚合索引”規(guī)則；當然，這種情況只是針對用戶經常修改記錄內容，特別是索引項的時候會負作用，但對于查詢速度并沒有影響。 如果您的聚集索引盲目地建在ID這個主鍵上時，查詢速度不一定會提高的，即使你在其他字段上建立非聚集索引。下面我們就來看一下在200萬條數據量的情況下各種查詢的速度表現：（1）全表掃描 只在主鍵上建立聚集索引：216。Select id,name,dept,emdate from person用時：20546毫秒（即：21秒） 不在主鍵上建立聚集索引，只建普通索引216。Select id,name,dept,emdate from person用時：17923毫秒（即：18秒）以上查詢執(zhí)行的實際上索引不會發(fā)揮作用，因為提取的是全部數據。聚集索引在這里會耗費更多的資源，所以會看到，不建立聚集索引比建立聚集索引還要快(2):按日期進行過濾(用到索引) 在主鍵上建立聚集索引，在emdate上建立非聚集索引：216。select id,name,dept,emdate from person where emdatedateadd(day,+1,getdate())用時：12376毫秒（12秒） 在主鍵上建立聚集索引，在emdate上沒有索引：216。select id,name,dept,emdate from person where emdatedateadd(day,+1,getdate())用時：21296毫秒（21秒） 在主鍵上建立非聚集索引，在emdate上建立非聚集索引：216。select id,name,dept,emdate from person where emdatedateadd(day,+1,getdate())用時：11590毫秒（12秒） 在主鍵上建立非聚集索引，在emdate上建立聚集索引：216。select id,name,dept,emdate from person where emdatedateadd(day,+1,getdate())andemdatedateadd(day,+3,getdate())用時：5233毫秒（5秒）雖然每條語句提取出來的都是30萬條數據，各種情況的差異卻是比較大的，特別是將聚集索引建立在日期列時的差異。事實上，如果您的數據庫真的有幾千萬條記錄的話，差距會更明顯。2:只要建立索引就能顯著提高查詢速度 這個想法是錯誤的。事實上，我們可以發(fā)現上面的例子中，上面按日期過濾的語句完全相同，且建立索引的字段也相同，但查詢速度卻有著非常大的差別。所以，并非是在任何字段上簡單地建立索引就能提高查詢速度。索引的建立，會帶來更多的系統(tǒng)開銷，因為系統(tǒng)要耗費資源去維護它 ，如果建立了沒有用到的索引，不適當的索引，過多的索引，反而會導致查詢性能下降?？傊饕慕?，要看表的結構，數據的分布，還有你要用到哪些數據，如果把索引建立在你根本不需要的數據列上，是根本不會發(fā)揮作用的。3:把所有需要提高查詢速度的字段都加進聚集索引，以提高查詢速度 這個不一定正確。上面已經談到。假設現在查詢要用到用戶名和日期這兩個字段，我們可以把他們合并起來，建立一個復合索引（pound index）。 很多人認為只要把任何字段加進聚集索引，就能提高查詢速度，也有人感到迷惑：如果把復合的聚集索引字段分開查詢，那么查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結果集都是25萬條）：（日期列emdate首先排在復合聚集索引的起始列，用戶名name排在后列） select id,name,dept,emdate from person where emdate216。39。2007060139。查詢速度：1664毫秒 select id,name,dept,emdate from person216。where emdate39。2007060139。 and name=’王小雪’查詢速度：1640毫秒 select gid,fariqi,neibuyonghu,title from person216。where name=39。王小雪39。查詢速度：5920毫秒從以上試驗中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到復合聚集索引的全部列的查詢速度是幾乎一樣的，而如果僅用復合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當然，語句2的查詢速度一樣是因為查詢的條目數一樣，如果復合索引的所有列都用上，而且查詢結果少的話，這樣就會形成“索引覆蓋”，因而性能可以達到最優(yōu)。同時，請記?。簾o論您是否經常使用聚合索引的其他列，但其前導列一定要是使用最頻繁的列。 其他索引經驗總結1:用聚合索引比用不是聚合索引的主鍵速度快下面是實例語句：（都是提取25萬條數據）select id,name,dept,emdate from person where emdate=39。2007060439。使用時間：906毫秒select id,name,dept,emdate from person where id=100000使用時間：1153毫秒這里，用聚合索引比用不是聚合索引的主鍵速度略快一些。2:用聚合索引比用一般的主鍵作order by時速度快，特別是小數據量時select id,name,dept,emdate from person order by emdate用時：17856 (約18秒)select id,name,dept,emdate from person order by id用時：44046 (約45秒)這里可以看到，用聚集索引比用一般的主鍵作order by時。事實上，有的資料說小數據量情況下，用聚集索引排序列比非聚集索引作為排序列快，10萬以上，則二者的速度差別不明顯。但據當前200萬條數據情況來看，在大數據量的情況下，這個結論依然成立。3:使用聚合索引內的時間段，搜索時間會按數據占整個數據表的百分比比例減少，而無論聚合索引使用了多少個select id,name,dept,emdate from person whereemdate=39。20070604 00:00:39。用時：1123毫秒（提取10萬條）select id,name,dept,emdate from person whereemdate=39。20070604 00:00:39。用時：1843毫秒（提取20萬條）select id,name,dept,emdate from person whereemdate=39。20070609 00:00:39。用時：4500毫秒（提取45萬條）從以上統(tǒng)計的數據看來，這個規(guī)律基本上是正確的其他注意事項 “水可載舟，亦可覆舟”，索引也一樣。索引有助于提高檢索性能，但過多或不當的索引也會導致系統(tǒng)低效。因為用戶在表中每加進一個索引，數據庫就要做更多的工作。過多的索引甚至會導致索引碎片。所以說，我們要建立一個“適當”的索引體系，特別是對聚合索引的創(chuàng)建，更應精益求精，以使您的數據庫能得到高性能的發(fā)揮。在實際的開發(fā)中，會遇到很多意想不到的情況，最好是多測試一些方案，找出哪種方案效率最高、最為有效。4:SQL語句改善 一個sql語句大約要經過三個階段，編譯優(yōu)化，執(zhí)行，取值，而編譯階段，而第一階段大部分情況下都要花掉60％的時間，所以綁定變量是很重要的，sqlserver和oracle都有緩存區(qū)，存放最近使用的sql語句，當有一條sql語句到達數據庫服務器時，數據庫會首先搜索緩存區(qū)，看它是否存在可以重用的sql語句，如果存在，則無需編譯優(yōu)化，因為緩存區(qū)的sql語句都是編譯優(yōu)化好了的，可以直接執(zhí)行，節(jié)省相當多的時間。如果沒有發(fā)現該語句，則必須要完全經歷語句編譯分析，優(yōu)化計劃，安全檢查等過程，這不僅耗費了大量的cpu功率，而且還在相當長的一段時間內鎖住了一部分數據庫緩存，這樣執(zhí)行sql語句的人越多，等待的時間越長，系統(tǒng)的性能會大幅度的下降。很多人不知道SQL語句在SQL SERVER中是如何執(zhí)行的，他們擔心自己所寫的SQL語句會被SQL SERVER誤解。比如：select id,name,dept,emdate from personwhere name=39。王小雪39。 and id100000 用時：1220毫秒和執(zhí)行:select * from table1 where id 100000 and name=39。王小雪39。 用時：1173毫秒一些人不知道以上兩條語句的執(zhí)行效率是否一樣，因為如果簡單的從語句先后上看，這兩個語句的確是不一樣，如果id是一個聚合索引，那么后一句僅僅從表的10000