「索引」這個名字，想必大家都耳熟能詳了，眾所周知，索引最大的用途就是提公升資料庫的查詢速度。或許，你會說，我曾經自己動手按書上講的方法試驗了一番，可是沒有感覺有多大速度的提公升呢？這完全是可能的，因為索引就像是一門非常厲害的武功招式，如果我們想發揮其最大的功力，光憑招式的純熟是遠遠不夠的，我們還必須同時修煉其高深的內功方可……
就上面的問題，首先，我們一般的學習和試驗情境中，很難會遇到大資料量的情況，什麼叫
大資料量？10000條算不算大？10萬、100萬呢……
就個人目前經歷的情況來看，一般只有上了10萬這個級別，才能初現索引的優勢，這也就是說，當我們通過小資料量資料庫進行實際操作的時候，可能只有通過使用函式的方法，才能在毫秒級別上得到乙個比較滿意的結果，但如果想從實際應用角度獲取「真實」的索引效果，大資料量是乙個必須的前提。
學習講究從0開始，我們就從索引的「招式」講起……
首先，請大家回憶一下，我們在使用漢語詞典查詢乙個漢字的時候，通常可以怎麼做？
對了，我們一般有兩種方法：首先，對於我們認識的字，我們可以直接通過其拼音的首字母進行初步定位，然後再通過後面的拼音進行逐次定位，最終找到漢字，如「索」字，我們首先通過其拼音「suo」可以知道，我們必須首先找到s，然後再翻找u，最後找到o，這時，我們再翻一兩頁一般就能找到我們要找的漢字了；但如果我們遇到乙個不認識的字，又該咋辦呢？例如「引」這個漢字，我們可以通過筆畫數或者偏旁部首進行查詢，即通過將筆畫數相同的所有漢字或者偏旁都一樣的所有漢字進行集中，並在其後附加上該字的具體頁碼，這樣，當我們逐個漢字進行查詢時，一旦找到這個漢字，我們就能馬上定位其所在的頁碼，可謂相當精確！
我們終於在字典中找到了「索引」這兩個漢字，先讓我們稍微慶祝一下，因為我們已經基本掌握了索引的原理了！你不信？好，讓我們細細談來……
無論是通過拼音直接查詢，還是通過筆畫，抑或是偏旁查詢，我們都是通過實現將這些漢字通過
某一種規則進行編排，然後，才能讓我們順利、快速地找到我們要找的漢字，那你有沒有想過有這麼一本字典，它包含很多的漢字，但是漢字的前後順序沒有任何規則。如果硬要你從這個字典中查到「索」這個漢字，你會怎麼做？撞大運，隨機進行抽取？雖然也是個辦法，但畢竟你能在有限次數內，恰翻到準確頁碼的機率萬分渺茫！最笨且最有效的方法就是從字典的第一頁逐頁進行查詢，直到找到那個漢字為止！如果你要找的漢字恰巧在首頁，你真是人品大爆發了，但如果你要找的漢字恰巧在最後一頁呢……
下面讓我們把索引和查字典關聯起來進行理解，那麼得到如下的對應關係：
字典
索引
拼音查詢
聚集索引
筆畫或偏旁查詢
非聚集索引
最好記著這個對應關係，一旦你對索引的概念有一點迷糊的時候，就翻起手邊的字典查兩個字，絕對有效！這就是武功招式的秘籍！
索引共分為兩招，第一招為聚集索引，第二招為非聚集索引。
聚集索引的排列順序和磁碟上物理資料儲存的順序是一致的，它擁有最快的查詢速度，且限定每乙個資料表只能有乙個聚集索引，這很顯然，因為物理資料只能有一種排序規則，對應到字典上，按拼音進行編排即為聚集索引，而字典的資料內容即可理解為物理資料。
所謂非聚集索引，即其只將設定的屬性列，按照設定的順序進行排列後的結果資料儲存到資料表中，我們可以將其理解成字典中的筆畫或偏旁查詢頁，其中只儲存有選定列的內容和其在磁碟中的實體地址，當我們找到所要找的資料時，也就意味著我們已經找到了它的物理儲存位址！相比聚集索引來說，它是一種非常精確的查詢方式。但是，有一點需要說明，因為非聚集索引需要一定的物理空間來儲存排序後的結果集，所以，選擇內容短小，經常用於查詢的列一方面提高了查詢速度，再者也不會對資料庫的容量有過多的影響。
很簡單吧，索引就是這麼簡單！既然我們已經把索引的招數熟記於心了，是時候提公升我們內功了。所謂內功即我們在何時，對那些屬性列建立何種索引？
在sql server中，資料庫會
自動為資料表的主鍵列建立聚集索引：我們通常情況下，會為乙個資料表建乙個id屬性列，用於唯一標識資料行內容，這樣做可以讓我們在檢視資料的時候獲得方便，但對於資料庫的查詢效能可沒有啥幫助，讓我們回想下字典的原理吧，如果乙個拼音就是乙個頁碼的話，我要想查詢乙個拼音的時候，只能退守到最原始的從頭至尾查詢方式！所以，預設的並不一定是最佳的，我們一定要理解這個概念。
下面就我們日常遇到的一些情況進行總結，並說明使用何種索引更能有效提公升效能（只是一般情況，但仍需要具體問題具體分析！）：
動作描述
使用聚集索引
使用非聚集索引
列經常被分組排序應應
返回某範圍內的資料應不應
乙個或極少不同值
不應不應
小數目的不同值應不應
大數目的不同值不應應
頻繁更新的列不應應
外來鍵列應
應主鍵列應應
頻繁修改索引列不應應
尤其要注意其中的「
小數目不同值」和「大數目不同值」，這往往需要我們的經驗來進行區別，沒有乙個具體的衡量標準。
索引雖然有諸多好處，但過多地建立索引有的時候可能會獲得相反的結果，例如可能導致資料庫容量過於臃腫、導致資料庫正常的insert,update和delete等操作的效能大大降低等，這就要求我們必須要多結合實際的情況進行分析，以建立最優的索引。
當然，如何編寫sql語句也是影響索引效能的乙個重要方面，下面有幾點需要特別留意：
1.日期屬性列，不會因為有分秒差別而減慢查詢速度
2.使用like比較進行查詢時，如果模式以特定字串如「abc%」開頭，使用索引則會提高效率；如果模式以萬用字元如「%xyz」開頭，則索引不起作用
3.or
會引起全表掃瞄，且和in的作用相當，但建立索引仍舊會有比較明顯的效果提公升~
4.盡量少用not
5.exists
和 in的執行效率是一樣的
6.用函式charindex()和前面加萬用字元%的like執行效率一樣
7.union
並不絕對比or的執行效率高
8.欄位提取要按照「需多少、提多少」的原則，避免「select *」
9.count(*)
不比count (字段)慢
10.
order by
按聚集索引列排序效率最高
11.
多用「top」進行資料提取，可提高效率
最後還是那句話，大家一定要活學多用，才能逐漸領悟索引的內功的奧妙，雖然索引的用法多變，但使用的原則不變，那就
是「簡單才是王道！」祝大家學習順利！
資料庫索引白話篇
索引 這個名字，想必大家都耳熟能詳了，眾所周知，索引最大的用途就是提公升資料庫的查詢速度。或許，你會說，我曾經自己動手按書上講的方法試驗了一番，可是沒有感覺有多大速度的提公升呢？這完全是可能的，因為索引就像是一門非常厲害的武功招式，如果我們想發揮其最大的功力，光憑招式的純熟是遠遠不夠的，我們還必須同...
資料庫總結 索引篇
索引是定義在儲存表的基礎上，有助於無需檢查所有記錄而快速定位所需記錄的一種輔助儲存結構，由一系列儲存在磁碟上的索引項組成，每一索引項又由兩部分構成。即索引欄位和行指標。由表中某些列通常是一列中的值串接而成。索引中通常儲存了索引欄位的每乙個值。指向表中包含索引字段值的記錄在磁碟上的儲存位置。儲存索引項...
資料庫篇 4 索引
索引的優勢 提高查詢效率 降低io的使用率 降低cpu使用率 因為b樹索引本身就是乙個排好序的結構，因此在排序時可以直接使用 索引的缺點 索引本身很大，可以存放在記憶體 硬碟 通常為硬碟 索引不是所有情況均適用 比如 資料量少 頻繁更新的字段 很少使用的字段等情況 所有索引會降低增刪改的效率 主鍵索...