在數(shù)據(jù)庫存優(yōu)化設計中往往會提到索引，這編文章就來詳細的說明一下在 SQL SERVER 下面的建立索引的技巧和需要注意的一些地方，讓您可以更直觀的了解數(shù)據(jù)庫的結(jié)構(gòu)。
往往在數(shù)據(jù)量比較小，查詢量也不是很大的時候我們往往會忽視索引的存在。
總結(jié)優(yōu)化如下:
1、主鍵就是聚集索引
2、只要建立索引就能顯著提高查詢速度
3、把所有需要提高查詢速度的字段都加進聚集索引，以提高查詢速度
(四)其他書上沒有的索引使用經(jīng)驗總結(jié)
1、用聚合索引比用不是聚合索引的主鍵速度快
2、用聚合索引比用一般的主鍵作order by時速度快，特別是在小數(shù)據(jù)量情況下
3、使用聚合索引內(nèi)的時間段，搜索時間會按數(shù)據(jù)占整個數(shù)據(jù)表的百分比成比例減少，而無論聚合索引使用了多少個
4 、日期列不會因為有分秒的輸入而減慢查詢速度
(五)其他注意事項
1. 不要索引常用的小型表
2. 不要把社會保障號碼(SSN)或身份證號碼(ID)選作鍵
3. 不要用用戶的鍵
4. 不要索引 memo/notes 字段和不要索引大型文本字段(許多字符)
5. 使用系統(tǒng)生成的主鍵
二、改善SQL語句
1、Like語句是否屬于SARG取決于所使用的通配符的類型
2、or 會引起全表掃描
3、非操作符、函數(shù)引起的不滿足SARG形式的語句
4、IN 的作用相當與OR
5、盡量少用NOT
6、exists 和 in 的執(zhí)行效率是一樣的
7、用函數(shù)charindex()和前面加通配符%的LIKE執(zhí)行效率一樣
8、union并不絕對比or的執(zhí)行效率高
9、字段提取要按照“需多少、提多少”的原則，避免“select *”
10、count(*)不比count(字段)慢
11、order by按聚集索引列排序效率最高
12、高效的TOP
(一)深入淺出理解索引結(jié)構(gòu)
實際上，您可以把索引理解為一種特殊的目錄。微軟的SQL SERVER提供了兩種索引：聚集索引(clustered index，也稱聚類索引、簇集索引)和非聚集索引(nonclustered index，也稱非聚類索引、非簇集索引)。下面，我們舉例來說明一下聚集索引和非聚集索引的區(qū)別：
其實，我們的漢語字典的正文本身就是一個聚集索引。比如，我們要查“安”字，就會很自然地翻開字典的前幾頁，因為“安”的拼音是“an”，而按照拼音排序漢字的字典是以英文字母“a”開頭并以“z”結(jié)尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”開頭的部分仍然找不到這個字，那么就說明您的字典中沒有這個字;同樣的，如果查“張”字，那您也會將您的字典翻到最后部分，因為“張”的拼音是“zhang”。也就是說，字典的正文部分本身就是一個目錄，您不需要再去查其他目錄來找到您需要找的內(nèi)容。
我們把這種正文內(nèi)容本身就是一種按照一定規(guī)則排列的目錄稱為“聚集索引”。
如果您認識某個字，您可以快速地從自典中查到這個字。但您也可能會遇到您不認識的字，不知道它的發(fā)音，這時候，您就不能按照剛才的方法找到您要查的字，而需要去根據(jù)“偏旁部首”查到您要找的字，然后根據(jù)這個字后的頁碼直接翻到某頁來找到您要找的字。但您結(jié)合“部首目錄”和“檢字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“張”字，我們可以看到在查部首之后的檢字表中“張”的頁碼是672頁，檢字表中“張”的上面是“馳”字，但頁碼卻是63頁，“張”的下面是“弩”字，頁面是390頁。很顯然，這些字并不是真正的分別位于“張”字的上下方，現(xiàn)在您看到的連續(xù)的“馳、張、弩”三字實際上就是他們在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我們可以通過這種方式來找到您所需要的字，但它需要兩個過程，先找到目錄中的結(jié)果，然后再翻到您所需要的頁碼。
我們把這種目錄純粹是目錄，正文純粹是正文的排序方式稱為“非聚集索引”。
通過以上例子，我們可以理解到什么是“聚集索引”和“非聚集索引”。
進一步引申一下，我們可以很容易的理解：每個表只能有一個聚集索引，因為目錄只能按照一種方法進行排序。
喜歡 
頂
難過
囧
圍觀
無聊
