這裡只看btree索引，至於雜湊索引和全文索引本文暫不討論。
前言：
索引是有效使用資料庫的基礎，但你的資料量很小的時候，或許通過掃瞄整表來訪問資料的效能還能接受，但當資料量極大時，當訪問量極大時，就一定需要通過索引的輔助才能有效地訪問資料。一般索引建立的好壞是效能好壞的成功關鍵。
使用innodb作為資料引擎的mysql和有聚集索引的sqlserver的資料儲存結構有點類似，雖然在物理層面，他們都儲存在page上，但在邏輯上面，我們可以把資料分為三塊：資料區域，索引區域，主鍵區域，他們通過主鍵的值作為關聯，配合工作。
乙個表資料空間中的索引資料區域中有很多索引，每乙個索引都是一顆b+tree，在非聚集索引的b+tree中索引的值作為b+tree的節點的key，資料主鍵作為節點的value。在innodb中，表資料檔案本身就是按b+tree組織的乙個索引結構，這棵樹的葉節點資料域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，因此innodb表資料檔案本身就是主鍵索引。這種索引也叫做聚集索引。
聚集索引查詢速度比非聚集索引快，是因為聚集索引只查詢一次，查詢到的元素的key就是主鍵，value就是資料記錄。
非聚集索引查詢要查詢兩次，第一次查詢到的元素的value為資料記錄的主鍵，再根據主鍵查詢匹配的資料記錄。
因為innodb的資料檔案本身要按主鍵聚集，所以innodb要求表必須有主鍵（myisam可以沒有），如果沒有顯式指定，則mysql系統會自動選擇乙個可以唯一標識資料記錄的列作為主鍵，如果不存在這種列，則mysql自動為innodb表生成乙個隱含字段作為主鍵，這個字段長度為6個位元組，型別為長整形。
磁碟io與預讀
前面提到了訪問磁碟，那麼這裡先簡單介紹一下磁碟io和預讀，磁碟讀取資料靠的是機械運動，每次讀取資料花費的時間可以分為尋道時間、旋轉延遲、傳輸時間三個部分，尋道時間指的是磁臂移動到指定磁軌所需要的時間，主流磁碟一般在5ms以下；旋轉延遲就是我們經常聽說的磁碟轉速，比如乙個磁碟7200轉，表示每分鐘能轉7200次，也就是說1秒鐘能轉120次，旋轉延遲就是1/120/2 = 4.17ms；
傳輸時間指的是從磁碟讀出或將資料寫入磁碟的時間，一般在零點幾毫秒，相對於前兩個時間可以忽略不計。
那麼訪問一次磁碟的時間，即一次磁碟io的時間約等於5+4.17 =9ms左右，聽起來還挺不錯的，
但要知道一台500 -mips的機器每秒可以執行5億條指令，因為指令依靠的是電的性質，換句話說執行一次io的時間可以執行40萬條指令，資料庫動輒十萬百萬乃至千萬級資料，每次9毫秒的時間，顯然是個災難。
考慮到磁碟io是非常高昂的操作，計算機作業系統做了一些優化，當一次io時，不光把當前磁碟位址的資料，而是把相鄰的資料也都讀取到記憶體緩衝區內，
因為區域性預讀性原理告訴我們，當計算機訪問乙個位址的資料的時候，與其相鄰的資料也會很快被訪問到。
每一次io讀取的資料我們稱之為一頁(page)。具體一頁有多大資料跟作業系統有關，一般為4k或8k，也就是我們讀取一頁內的資料時候，實際上才發生了一次io，這個理論對於索引的資料結構設計非常有幫助。
復合索引：（索引的最左匹配特性）
當b+樹的資料項是復合的資料結構，比如(name,age,***)的時候，b+數是按照從左到右的順序來建立搜尋樹的，比如當(張三,20,f)這樣的資料來檢索的時候，b+樹會優先比較name來確定下一步的所搜方向，如果name相同再依次比較age和***，最後得到檢索的資料；但當(20,f)這樣的沒有name的資料來的時候，b+樹就不知道下一步該查哪個節點，因為建立搜尋樹的時候name就是第乙個比較因子，必須要先根據name來搜尋才能知道下一步去**查詢。
比如當(張三,f)這樣的資料來檢索時，b+樹可以用name來指定搜尋方向，但下乙個欄位age的缺失，所以只能把名字等於張三的資料都找到，然後再匹配性別是f的資料了，
這個是非常重要的性質，即索引的最左匹配特性。
優化原則：
1.最左字首匹配原則，非常重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。
2.=和in可以亂序，比如a = 1 and b = 2 and c = 3建立(a,b,c)索引可以任意順序，mysql的查詢優化器會幫你優化成索引可以識別的形式
3.盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃瞄的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別字段可能在大資料面前區分度就是0，
那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃瞄10條記錄
4.索引列不能參與計算，保持列「乾淨」，比如from_unixtime(create_time) = '2014-05-29'就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的字段值，
但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp('2014-05-29');
5.盡量的擴充套件索引，不要新建索引。比如表中已經有a的索引，現在要加(a,b)的索引，那麼只需要修改原來的索引即可
慢查詢優化基本步驟：
0.先執行看看是否真的很慢，注意設定sql_no_cache1.where條件單錶查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單錶每個字段分別查詢，看哪個欄位的區分度最高
2.explain檢視執行計畫，是否與1預期一致（從鎖定記錄較少的表開始查詢）
3.order by limit 形式的sql語句讓排序的表優先查
4.了解業務方使用場景
5.加索引時參照建索引的幾大原則
6.觀察結果，不符合預期繼續從0分析
復合索引（組合索引）
使用者可以在多個列上建立索引，這種索引叫做復合索引 組合索引 1.何時是用復合索引 在where條件中字段用索引，如果用多字段就用復合索引。比如在查詢位址的時候，經常要求輸入省，市資訊，如果同時在省，市上建立索引，將會提高查詢速度。2.對於復合索引，在查詢使用時，最好將條件順序按找索引的順序，這樣效...
復合索引（組合索引）
使用者可以在多個列上建立索引，這種索引叫做復合索引 組合索引 1.何時是用復合索引 在where條件中字段用索引，如果用多字段就用復合索引。比如在查詢位址的時候，經常要求輸入省，市資訊，如果同時在省，市上建立索引，將會提高查詢速度。2.對於復合索引，在查詢使用時，最好將條件順序按找索引的順序，這樣效...
復合索引 復合索引順序選擇問題
color red b 注意！在較高版本的oracle中不存在下述的問題！b color 復合索引第乙個原則 字首性 prefixing color red 復合索引的字首性是指只有當復合索引的第乙個字段出現在sql語句的謂詞條件中時，該索引才會被用到。如復合索引為 ename,job,mgr 只要...