聚集索引與非聚集索引詳解

SQL中、聚集索引和非聚集索引有何區(qū)別？聚集索引和非聚集索引的根本區(qū)別是表記錄的排列順序和與索引的排列順序是否一致，聚集索引表記錄的排列順序與索引的排列順序一致，優(yōu)點(diǎn)是查詢速度快，因?yàn)橐坏┚哂械谝粋€索引值的紀(jì)錄被找到，具有連續(xù)索引值的記錄也一定物理的緊跟其后。聚集索引的缺點(diǎn)是對表進(jìn)行修改速度較慢，這是為了保持表中的記錄的物理順序與索引的順序一致，而把記錄插入到數(shù)據(jù)頁的相應(yīng)位置，必須在數(shù)據(jù)頁中進(jìn)行數(shù)據(jù)重排，降低了執(zhí)行速度。建議使用聚集索引的場合為： a.此列包含有限數(shù)日的不同值； b.查詢的結(jié)果返回一個區(qū)間的值;c.查詢的結(jié)果返回某值相同的大量結(jié)果集。 非聚集索引指定了表中記錄的邏輯順序，但記錄的物理順序和索引的順序不一致，聚集索引和非聚集索引都采用了B+樹的結(jié)構(gòu)，但非聚集索引的葉子層并不與實(shí)際的數(shù)據(jù)頁相重疊，而采用葉子層包含一個指向表中的記錄在數(shù)據(jù)頁中的指針的方式。非聚集索引比聚集索引層次多，添加記錄不會引起數(shù)據(jù)順序的重組。建議使用非聚集索引的場合為： a.此列包含了大量數(shù)日不同的值； b.查詢的結(jié)束返回的是少量的結(jié)果集；c.orderby子句中使用了該列。聚集索引:表中存儲的數(shù)據(jù)按照索引的順序存儲,檢索效率比普通索引高，但對數(shù)據(jù)新增/修改/刪除的影響比較大非聚集索引:不影響表中的數(shù)據(jù)存儲順序，檢索效率比聚集索引低，對數(shù)據(jù)新增/修改/刪除的影響很少主要是存儲的順序的調(diào)整不同。這樣對一些操作的影響不同。有利就有弊，兩個之間屬于對立和彌補(bǔ)的關(guān)系。主要看你需要怎樣的應(yīng)用了。聚集索引將數(shù)據(jù)行的鍵值在表內(nèi)排序并存儲對應(yīng)的數(shù)據(jù)記錄，使得數(shù)據(jù)表物理順序與索引順序一致一個表只能有一個聚集索引非聚集索引是完全獨(dú)立與數(shù)據(jù)行的結(jié)構(gòu)，表中的數(shù)據(jù)行不按非聚集鍵的次序存儲，存儲數(shù)據(jù)過程中不會影響數(shù)據(jù)表中記錄的實(shí)際存儲順序每個表可以創(chuàng)建249個非聚集索引1對于經(jīng)常更新的列不宜建立聚集索引2具有高百分比的唯一值和不經(jīng)常被修改的屬性上創(chuàng)建聚集索引例如：主鍵3若在一個表中既要創(chuàng)建聚集索引，又要創(chuàng)建非聚集索引，應(yīng)先創(chuàng)建聚集索引，然后創(chuàng)建非聚集索引SQLServer創(chuàng)建索引什么是索引拿漢語字典的日錄頁（索引）打比方：正如漢語字典中的漢字按頁存放一樣，SQLServer中的數(shù)據(jù)記錄也是按頁存放的，每頁容量一般為4K。為了加快查找的速度，漢語字（詞）典一般都有按拼音、筆畫、偏旁部首等排序的日錄（索引），我們可以選擇按拼音或筆畫查找方式，快速查找到需要的字（詞）。同理，SQLServer允許用戶在表中創(chuàng)建索引，指定按某列預(yù)先排序，從而大大提高查詢速度。?SQLServer中的數(shù)據(jù)也是按頁（4KB）存放? 索引：是SQLServer編排數(shù)據(jù)的內(nèi)部方法。它為SQLServer提供一種方法來編排查詢數(shù)據(jù)。? 索引頁：數(shù)據(jù)庫中存儲索引的數(shù)據(jù)頁；索引頁類似于漢語字（詞）典中按拼音或筆畫排序的日錄頁。? 索引的作用：通過使用索引，可以大大提高數(shù)據(jù)庫的檢索速度，改善數(shù)據(jù)庫性能。索引類型? 唯一索引：唯一索引不允許兩行具有相同的索引值?主鍵索引：為表定義一個主鍵將自動創(chuàng)建主鍵索引，主鍵索引是唯一索引的特殊類型。主鍵索引要求主鍵中的每個值是唯一的，并且不能為空? 聚集索引（Clustered）：表中各行的物理順序與鍵值的邏輯（索引）順序相同，每個表只能有一個? 非聚集索引（Non-clustered）：非聚集索引指定表的邏輯順序。數(shù)據(jù)存儲在一個位置，索引存儲在另一個位置，索引中包含指向數(shù)據(jù)存儲位置的指針?？梢杂卸鄠€，小于249個索引類型：再次用漢語字典打比方，希望大家能夠明白聚集索引和非聚集索引這兩個概念。唯一索引：唯一索引不允許兩行具有相同的索引值。如果現(xiàn)有數(shù)據(jù)中存在重復(fù)的鍵值，則大多數(shù)數(shù)據(jù)庫都不允許將新創(chuàng)建的唯一索引與表一起保存。當(dāng)新數(shù)據(jù)將使表中的鍵值重復(fù)時，數(shù)據(jù)庫也拒絕接受此數(shù)據(jù)。例如，如果在stuInfo表中的學(xué)員員身份證號(stuID)列上創(chuàng)建了唯一索引，則所有學(xué)員的身份證號不能重復(fù)。提示：創(chuàng)建了唯一約束，將自動創(chuàng)建唯一索引。盡管唯一索引有助于找到信息，但為了獲得最佳性能，建議使用主鍵約束或唯一約束。主鍵索引：在數(shù)據(jù)庫關(guān)系圖中為表定義一個主鍵將自動創(chuàng)建主鍵索引，主鍵索引是唯一索引的特殊類型。主鍵索引要求主鍵中的每個值是唯一的。當(dāng)在查詢中使用主鍵索引時，它還允許快速訪問數(shù)據(jù)。聚集索引(clusteredindex)在聚集索引中，表中各行的物理順序與鍵值的邏輯(索引)順序相同。表只能包含一個聚集索引。例如：漢語字(詞)典默認(rèn)按拼音排序編排字典中的每頁頁碼。拼音字母a，b，c，d……x，y，z就是索引的邏輯順序，而頁碼1,2,3......就是物理順序。默認(rèn)按拼音排序的字典，其索引順序和邏輯順序是一致的。即拼音順序較后的字（詞）對應(yīng)的頁碼也較大。如拼音ha”對應(yīng)的字（詞）頁碼就比拼音ba”對應(yīng)的字（詞）頁碼靠后。非聚集索引（Non-clustered）如果不是聚集索引，表中各行的物理順序與鍵值的邏輯順序不匹配。聚集索引比非聚集索引（nonclusteredindex）有更快的數(shù)據(jù)訪問速度。例如，按筆畫排序的索引就是非聚集索引，1”畫的字（詞）對應(yīng)的頁碼可能比3”畫的字（詞）對應(yīng)的頁碼大（靠后）。提示：SQLServer中，一個表只能創(chuàng)建1個聚集索引，多個非聚集索引。設(shè)置某列為主鍵，該列就默認(rèn)為聚集索引如何創(chuàng)建索引使用T-SQL語句創(chuàng)建索引的語法：CREATE[UNIQUE][CLUSTERED|NONCLUSTERED]INDEXindex_nameONtable_name（column_name...）[WITHFILLFACTOR=x]UNIQUE表示唯一索引，可選CLUSTERED,NONCLUSTERED表示聚集索弓I還是非聚集索引，可選q FILLFACTOR表示填充因子，指定一個0到100之間的值，該值指示索引頁填滿的空間所占的百分比在stuMarks表的writtenExam列創(chuàng)建索引：USEstuDBGOIFEXISTS(SELECTnameFROMsysindexesWHEREname='IX_writtenExam')DROPINDEXstuMarks.IX_writtenExam/*--筆試列創(chuàng)建非聚集索引：填充因子為30%--*/CREATENONCLUSTEREDINDEXIX_writtenExamONstuMarks(writtenExam)WITHFILLFACTOR=30GO/*——指定按索引IX_writtenExam查詢----*/SELECT*FROMstuMarks(INDEX=IX_writtenExam)WHEREwrittenExamBETWEEN60AND90雖然我們可以指定SQLServer按哪個索引進(jìn)行數(shù)據(jù)查詢，但一般不需要我們?nèi)斯ぶ付āQLServer將會根據(jù)我們創(chuàng)建的索引，自動優(yōu)化查詢。索引的優(yōu)缺點(diǎn)? 優(yōu)點(diǎn)加快訪問速度加強(qiáng)行的唯一性? 缺點(diǎn)帶索引的表在數(shù)據(jù)庫中需要更多的存儲空間操縱數(shù)據(jù)的命令需要更長的處理時間，因?yàn)樗鼈冃枰獙λ饕M(jìn)行更新創(chuàng)建索引的指導(dǎo)原則? 請按照下列標(biāo)準(zhǔn)選擇建立索引的列。該列用于頻繁搜索該列用于對數(shù)據(jù)進(jìn)行排序? 請不要使用下面的列創(chuàng)建索引：列中僅包含幾個不同的值。表中僅包含幾行。為小型表創(chuàng)建索引可能不太劃算，因?yàn)镾QLServer在索引中搜索數(shù)據(jù)所花的時間比在表中逐行搜索所花的時間更長一、深入淺出理解索引結(jié)構(gòu)實(shí)際上，您可以把索引理解為一種特殊的日錄。微軟的SQLSERVER提供了兩種索引：聚集索引（clusteredindex，也稱聚類索引、簇集索引）和非聚集索引（nonclusteredindex，也稱非聚類索引、非簇集索引）。下面，我們舉例來說明一下聚集索引和非聚集索引的區(qū)別：其實(shí)，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查，，安，，字，就會很自然地翻開字典的前幾頁，因?yàn)?，，安，，的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結(jié)尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那么就說明您的字典中沒有這個字；同樣的，如果查“張”字，那您也會將您的字典翻到最后部分，因?yàn)椤皬垺钡钠匆羰恰皕hang”。也就是說，字典的正文部分本身就是一個日錄，您不需要再去查其他日錄來找到您需要找的內(nèi)容。我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的日錄稱為“聚集索引”。如果您認(rèn)識某個字，您可以快速地從自動中查到這個字。但您也可能會遇到您不認(rèn)識的字，不知道它的發(fā)音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據(jù)偏旁部首查到您要找的字，然后根據(jù)這個字后的頁碼直接翻到某頁來找到您要找的字。但您結(jié)合部首日錄和檢字表而查到的字的排序并不是真正的正文的排序方法，比如您查張字，我們可以看到在查部首之后的檢字表中張的頁碼是672頁，檢字表中張的上面是馳字，但頁碼卻是63頁，張的下面是弩字，頁面是390頁。很顯然，這些字并不是真正的分別位于張字的上下方，現(xiàn)在您看到的連續(xù)的馳、張、弩三字實(shí)際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到日錄中的結(jié)果，然后再翻到您所需要的頁碼。我們把這種日錄純粹是日錄，正文純粹是正文的排序方式稱為非聚集索引。通過以上例子，我們可以理解到什么是聚集索引和非聚集索引。進(jìn)一步引中一下，我們可以很容易的理解：每個表只能有一個聚集索引，因?yàn)槿珍浿荒馨凑找环N方法進(jìn)行排序。二、何時使用聚集索引或非聚集索引下面的表總結(jié)了何時使用聚集索引或非聚集索引（很重要）：動作描述 使用聚集索引使用非聚集索引列經(jīng)常被分組排序應(yīng)應(yīng)返回某范圍內(nèi)的數(shù)據(jù)應(yīng)不應(yīng)一個或極少不同值不應(yīng)不應(yīng)小數(shù)日的不同值應(yīng)不應(yīng)大數(shù)日的不同值不應(yīng)應(yīng)頻繁更新的列不應(yīng)應(yīng)外鍵列應(yīng) 應(yīng)主鍵列應(yīng) 應(yīng)頻繁修改索引列不應(yīng)應(yīng)事實(shí)上，我們可以通過前面聚集索引和非聚集索引的定義的例子來理解上表。如：返回某范圍內(nèi)的數(shù)據(jù)一項(xiàng)。比如您的某個表有一個時間列，恰好您把聚合索引建立在了該列，這時您查詢2004年1月1日至2004年10月1日之間的全部數(shù)據(jù)時，這個速度就將是很快的，因?yàn)槟倪@本字典正文是按日期進(jìn)行排序的，聚類索引只需要找到要檢索的所有數(shù)據(jù)中的開頭和結(jié)尾數(shù)據(jù)即可；而不像非聚集索引，必須先查到日錄中查到每一項(xiàng)數(shù)據(jù)對應(yīng)的頁碼，然后再根據(jù)頁碼查到具體內(nèi)容。三、結(jié)合實(shí)際，談索引使用的誤區(qū)理論的日的是應(yīng)用。雖然我們剛才列出了何時應(yīng)使用聚集索引或非聚集索引，但在實(shí)踐中以上規(guī)則卻很容易被忽視或不能根據(jù)實(shí)際情況進(jìn)行綜合分析。下面我們將根據(jù)在實(shí)踐中遇到的實(shí)際問題來談一下索引使用的誤區(qū)，以便于大家掌握索引建立的方法。1、主鍵就是聚集索引這種想法筆者認(rèn)為是極端錯誤的，是對聚集索引的一種浪費(fèi)。雖然SQLSERVER默認(rèn)是在主鍵上建立聚集索引的。通常，我們會在每個表中都建立一個ID列，以區(qū)分每條數(shù)據(jù)，并且這個ID列是自動增大的，步長一般為1。我們的這個辦公自動化的實(shí)例中的列Gid就是如此。此時，如果我們將這個列設(shè)為主鍵，SQLSERVER會將此列默認(rèn)為聚集索引。這樣做有好處，就是可以讓您的數(shù)據(jù)在數(shù)據(jù)庫中按照ID進(jìn)行物理排序，但筆者認(rèn)為這樣做意義不大。顯而易見，聚集索引的優(yōu)勢是很明顯的，而每個表中只能有一個聚集索引的規(guī)則，這使得聚集索引變得更加珍貴。從我們前面談到的聚集索引的定義我們可以看出，使用聚集索引的最大好處就是能夠根據(jù)查詢要求，迅速縮小查詢范圍，避免全表掃描。在實(shí)際應(yīng)用中，因?yàn)镮D號是自動生成的，我們并不知道每條記錄的ID號，所以我們很難在實(shí)踐中用ID號來進(jìn)行查詢。這就使讓ID號這個主鍵作為聚集索引成為一種資源浪費(fèi)。其次，讓每個ID號都不同的字段作為聚集索引也不符合大數(shù)日的不同值情況下不應(yīng)建立聚合索引規(guī)則；當(dāng)然，這種情況只是針對用戶經(jīng)常修改記錄內(nèi)容，特別是索引項(xiàng)的時候會負(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ù)庫的開銷而已。事實(shí)上，我們完全可以讓用戶打開系統(tǒng)首頁時，數(shù)據(jù)庫僅僅查詢這個用戶近3個月來未閱覽的文件，通過日期這個字段來限制表掃描，提高查詢速度。如果您的辦公自動化系統(tǒng)已經(jīng)建立的2年，那么您的首頁顯示速度理論上將是原來速度8倍，甚至更快。在這里之所以提到理論上三字，是因?yàn)槿绻木奂饕€是盲日地建在ID這個主鍵上時，您的查詢速度是沒有這么高的，即使您在日期這個字段上建立的索引（非聚合索引）。下面我們就來看一下在1000萬條數(shù)據(jù)量的情況下各種查詢的速度表現(xiàn)（3個月內(nèi)的數(shù)據(jù)為25萬條）：（1） 僅在主鍵上建立聚集索引，并且不劃分時間段：Selectgid,fariqi,neibuyonghu,titlefromtgongwen用時：128470毫秒（即：128秒）（2） 在主鍵上建立聚集索引，在fariq上建立非聚集索引：selectgid,fariqi,neibuyonghu,titlefromTgongwenwherefariqi>dateadd（day,-90,getdate（））用時：53763毫秒（54秒）（3）將聚合索引建立在日期列（fariqi）上:selectgid,fariqi,neibuyonghu,titlefromTgongwenwherefariqi>dateadd(day,-90,getdate())用時：2423毫秒(2秒)雖然每條語句提取出來的都是25萬條數(shù)據(jù)，各種情況的差異卻是巨大的，特別是將聚集索引建立在日期列時的差異。事實(shí)上，如果您的數(shù)據(jù)庫真的有1000萬容量的話，把主鍵建立在ID列上，就像以上的第1、2種情況，在網(wǎng)頁上的表現(xiàn)就是超時，根本就無法顯示。這也是我摒棄ID列作為聚集索引的一個最重要的因素。得出以上速度的方法是：在各個select語句前加：declare@ddatetimeset@d=getdate()并在select語句后加：select[語句執(zhí)行花費(fèi)時間(毫秒)]=datediff(ms,@d,getdate())2、只要建立索引就能顯著提高查詢速度事實(shí)上，我們可以發(fā)現(xiàn)上面的例子中，第2、3條語句完全相同，且建立索引的字段也相同；不同的僅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查詢速度卻有著天壤之別。所以，并非是在任何字段上簡單地建立索引就能提高查詢速度。從建表的語句中，我們可以看到這個有著1000萬數(shù)據(jù)的表中fariqi字段有5003個不同記錄。在此字段上建立聚合索引是再合適不過了。在現(xiàn)實(shí)中，我們每天都會發(fā)幾個文件，這幾個文件的發(fā)文日期就相同，這完全符合建立聚集索引要求的：既不能絕大多數(shù)都相同，又不能只有極少數(shù)相同的規(guī)則。由此看來，我們建立適當(dāng)?shù)木酆纤饕龑τ谖覀兲岣卟樵兯俣仁欠浅Ｖ匾摹?、把所有需要提高查詢速度的字段都加進(jìn)聚集索引，以提高查詢速度上面已經(jīng)談到：在進(jìn)行數(shù)據(jù)查詢時都離不開字段的是日期還有用戶本身的用戶名。既然這兩個字段都是如此的重要，我們可以把他們合并起來，建立一個復(fù)合索引（compoundindex）。很多人認(rèn)為只要把任何字段加進(jìn)聚集索引，就能提高查詢速度，也有人感到迷惑：如果把復(fù)合的聚集索引字段分開查詢，那么查詢速度會減慢嗎？帶著這個問題，我們來看一下以下的查詢速度（結(jié)果集都是25萬條數(shù)據(jù)）：（日期列fariqi首先排在復(fù)合聚集索引的起始列，用戶名neibuyonghu排在后列）：（1） selectgid,fariqi,neibuyonghu,titlefromTgongwenwherefariqi>"2004-5-5"查詢速度：2513毫秒（2） selectgid,fariqi,neibuyonghu,titlefromTgongwenwherefariqi>''2004-5-5''andneibuyonghu=''辦公室”查詢速度：2516毫秒（3） selectgid,fariqi,neibuyonghu,titlefromTgongwenwhereneibuyonghu=''辦公室”查詢速度：60280毫秒從以上試驗(yàn)中，我們可以看到如果僅用聚集索引的起始列作為查詢條件和同時用到復(fù)合聚集索引的全部列的查詢速度是幾乎一樣的，甚至比用上全部的復(fù)合索引列還要略快（在查詢結(jié)果集數(shù)日一樣的情況下）；而如果僅用復(fù)合聚集索引的非起始列作為查詢條件的話，這個索引是不起任何作用的。當(dāng)然，語句1、2的查詢速度一樣是因?yàn)椴樵兊臈l日數(shù)一樣，如果復(fù)合索引的所有列都用上，而且查詢結(jié)果少的話，這樣就會形成索引覆蓋，因而性能可以達(dá)到最優(yōu)。同時，請記?。簾o論您是否經(jīng)常使用聚合索引的其他列，但其前導(dǎo)列一定要是使用最頻繁的列。四、其他書上沒有的索引使用經(jīng)驗(yàn)總結(jié)1、用聚合索引比用不是聚合索引的主鍵速度快下面是實(shí)例語句：（都是提取25萬條數(shù)據(jù)）selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi="2004-9-16"使用時間：3326毫秒selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwheregid<=250000使用時間：4470毫秒這里，用聚合索引比用不是聚合索引的主鍵速度快了近1/4。2、用聚合索引比用一般的主鍵作orderby時速度快，特別是在小數(shù)據(jù)量情況下selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenorderbyfariqi用時：12936selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenorderbygid用時：18843這里，用聚合索引比用一般的主鍵作orderby時，速度快了3/10。事實(shí)上，如果數(shù)據(jù)量很小的話，用聚集索引作為排序列要比使用非聚集索引速度快得明顯的多；而數(shù)據(jù)量如果很大的話，如10萬以上，則二者的速度差別不明顯。3、使用聚合索引內(nèi)的時間段，搜索時間會按數(shù)據(jù)占整個數(shù)據(jù)表的百分比成比例減少，而無論聚合索引使用了多少個：selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi>"2004-1-1"用時：6343毫秒（提取100萬條）selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi>"2004-6-6"用時：3170毫秒（提取50萬條）selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi="2004-9-16"用時：3326毫秒（和上句的結(jié)果一模一樣。如果采集的數(shù)量一樣，那么用大于號和等于號是一樣的）selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi>''2004-1-1''andfariqi<"2004-6-6"用時：3280毫秒4、日期列不會因?yàn)橛蟹置氲妮斎攵鴾p慢查詢速度下面的例子中，共有100萬條數(shù)據(jù)，2004年1月1日以后的數(shù)據(jù)有50萬條，但只有兩個不同的日期，日期精確到日；之前有數(shù)據(jù)50萬條，有5000個不同的日期，日期精確到秒。selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi>''2004-1-1''orderbyfariqi用時：6390毫秒selectgid,fariqi,neibuyonghu,reader,titlefromTgongwenwherefariqi<''2004-1-1''orderbyfariqi用時：6453毫秒五、其他注意事項(xiàng)水可載舟，亦可覆舟，索引也一樣。索引有助于提高檢索性能，但過多或不當(dāng)?shù)乃饕矔?dǎo)致系統(tǒng)低效。因?yàn)橛脩粼诒碇忻考舆M(jìn)一個索引，數(shù)據(jù)庫就要做更多的工作。過多的索引甚至?xí)?dǎo)致索引碎片。所以說，我們要建立一個適當(dāng)?shù)乃饕w系，特別是對聚合索引的創(chuàng)建，更應(yīng)精益求精，以使您的數(shù)據(jù)庫能得到高性能的發(fā)揮。當(dāng)然，在實(shí)踐中，作為一個盡職的數(shù)據(jù)庫管理員，您還要多測試一些方案，找出哪種方案效率最高、最為有效。SQLSERVER性能優(yōu)化（強(qiáng)制使用索引查詢）實(shí)地測試了一下，發(fā)現(xiàn)完全是扯淡（至少對于sql2005），微軟的數(shù)據(jù)庫引擎要是這腦殘，早該倒閉了，sql的速度90%取決于索引，不是sql語句（用<>,isnull,in,or之類不能使用索引，這里我要吐槽一下，mssql里唯一鍵都認(rèn)為null和其它值地位一樣，只能有一個，isnull不能使用索引？），啥視圖（表連接順序），存儲過程化（一句話也要寫成存儲過程）都是浮云，唯一要注意的是多條件注意on、where、having這三個的順序，on是最先執(zhí)行，where次之，having最后。內(nèi)連接的時候，把能過濾掉較多數(shù)據(jù)的條件寫在on后能加快查詢速度。非內(nèi)連接，嘿嘿。。。。。。再來說說被神化了的存儲過程化的實(shí)際性能，從sql事務(wù)里我們知道，存儲過程是一個整體，用面向?qū)ο蟮乃枷雭碚f，一個類，而類內(nèi)部成員可以互相訪問，所以對于重復(fù)的sql語句，可在首次執(zhí)行該過程后使用該過程的內(nèi)存中版本，所以大家應(yīng)該把心思放在優(yōu)化可讀性上，而不是優(yōu)化啥寫法上。而流傳最廣的減少編譯時間，減少網(wǎng)絡(luò)流量，這個起的效果真是浮云，對于一般就幾十行的代碼，我實(shí)地測試，編譯時間才3毫秒，除非你想寫n長n長的邏輯......視圖我就直接抄msdn的一段話：視圖也稱為虛擬表，因?yàn)橐晥D所返回的結(jié)果集的一般格式與表相同，都是由列和行組成，而且在SQL語句中引用視圖的方式也與引用表的方式相同。標(biāo)準(zhǔn)視圖的結(jié)果集不是永久地存儲在數(shù)據(jù)庫中。每次查詢引用標(biāo)準(zhǔn)視圖時，S