舉例說明：
假設有一個圖書Book表，裏面有字段id，name, isbn等。如果圖書數量巨大的話，我們通過isbn查詢通常是比較慢的。
這裏寫圖片描述
添加索引：
create index index_isbn ON book (isbn);
再次執行查詢：
這裏寫圖片描述
查詢時間從0.134縮短到0.001,效果還是很明顯的。
接下來通過一個故事來說明一下，索引是什麼？
很久以前，在一個古城的的大圖書館中珍藏有成千上萬本書籍，但書架上的書沒有按任何順序擺放，因此每當有人詢問某本書時，圖書管理員只有挨個尋找，每一次都要花費大量的時間。[這就好比數據表沒有主鍵一樣，搜索表中的數據時，數據庫引擎必須進行全表掃描，效率極其低下。]
更糟的是圖書館的圖書越來越多，圖書管理員的工作變得異常痛苦，有一天來了一個聰明的小夥子，他看到圖書管理員的痛苦工作後，想出了一個辦法，他建議將每本書都編上號，然後按編號放到書架上，如果有人指定了圖書編號，那麼圖書管理員很快就可以找到它的位置了。
[給圖書編號就象給表創建主鍵一樣，創建主鍵時，會創建聚集索引樹，表中的所有行會在文件系統上根據主鍵值進行物理排序，當查詢表中任一行時，數據庫首先使用聚集索引樹找到對應的數據頁(就象首先找到書架一樣)，然後在數據頁中根據主鍵鍵值找到目標行(就象找到書架上的書一樣)。]
於是圖書管理員開始給圖書編號，然後根據編號將書放到書架上，爲此他花了整整一天時間，但最後經過測試，他發現找書的效率大大提高了。[在一個表上只能創建一個聚集索引，就象書只能按一種規則擺放一樣。]
但問題並未完全解決，因爲很多人記不住書的編號，只記得書的名字，圖書管理員無賴又只有掃描所有的圖書編號挨個尋找，但這次他只花了20分鐘，以前未給圖書編號時要花2-3小時，但與根據圖書編號查找圖書相比，時間還是太長了，因此他向那個聰明的小夥子求助。
[這就好像你給Product表增加了主鍵ProductID，但除此之外沒有建立其它索引，當使用Product Name進行檢索時，數據庫引擎又只要進行全表掃描，逐個尋找了。]
聰明的小夥告訴圖書管理員，之前已經創建好了圖書編號，現在只需要再創建一個索引或目錄，將圖書名稱和對應的編號一起存儲起來，但這一次是按圖書名稱進行排序，如果有人想找“Database Management System”一書，你只需要跳到“D”開頭的目錄，然後按照編號就可以找到圖書了。
於是圖書管理員興奮地花了幾個小時創建了一個“圖書名稱”目錄，經過測試，現在找一本書的時間縮短到1分鐘了(其中30秒用於從“圖書名稱”目錄中查找編號，另外根據編號查找圖書用了30秒)。
圖書管理員開始了新的思考，讀者可能還會根據圖書的其它屬性來找書，如作者，於是他用同樣的辦法爲作者也創建了目錄，現在可以根據圖書編號，書名和作者在1分鐘內查找任何圖書了，圖書管理員的工作變得輕鬆了，故事也到此結束。
通過這個故事很容易理解索引的真正含義。假設我們有一個Products表，創建了一個聚集索引(根據表的主鍵自動創建的)，我們還需要在ProductName列上創建一個非聚集索引，創建非聚集索引時，數據庫引擎會爲非聚集索引自動創建一個索引樹(就象故事中的“圖書名稱”目錄一樣)，產品名稱會存儲在索引頁中，每個索引頁包括一定範圍的產品名稱和它們對應的主鍵鍵值，當使用產品名稱進行檢索時，數據庫引擎首先會根據產品名稱查找非聚集索引樹查出主鍵鍵值，然後使用主鍵鍵值查找聚集索引樹找到最終的產品。
確保每個表都有主鍵
這樣可以確保每個表都有聚集索引(表在磁盤上的物理存儲是按照主鍵順序排列的)，使用主鍵檢索表中的數據，或在主鍵字段上進行排序，或在where子句中指定任意範圍的主鍵鍵值時，其速度都是非常快的。
在下面這些列上創建非聚集索引：
1)搜索時經常使用到的;
2)用於連接其它表的;
3)用於外鍵字段的;
4)高選中性的;
5)ORDER BY子句使用到的;
增加普通索引和UNIQUE兩種索引。其格式如下：
create index index_name on table_name (column_list) ;
create unique index index_name on table_name (column_list) ;
刪除索引
drop index index_name on table_name ;
alter table table_name drop index index_name ;