索引根據底層實作可分為B-Tree索引和雜湊索引，大部分時候我們使用的都是B -Tree索引，因為它良好的效能和特性更適合於建構高並發系統。
根據索引的儲存方式來劃分，索引可以分為叢集索引和非叢集索引。非聚集索引的葉子節點僅包含所有欄位和主鍵ID，而叢集索引的葉子節點則包含了完整的記錄行。
根據叢集索引和非叢集索引還能繼續下分還能分為普通索引、覆蓋索引、唯一索引以及聯合索引等。
叢集索引也叫聚集索引，它其實不是一種單獨的索引類型，而是一種資料儲存方式，聚集索引的葉子節點保存了一行記錄的所有列資訊。也就是說，聚集索引的葉子節點中，包含了一個完整的記錄行。
非叢集索引也叫輔助索引、普通索引，它的葉子節點只包含一個主鍵值，透過非叢集索引找出記錄要先找到主鍵，然後再透過主鍵到叢集索引中找到對應的記錄行，這個過程稱為回表。
例如包含了使用者名稱和年齡的資料表，假設主鍵是使用者ID，叢集索引的結構為（橘色的代表id，綠色是指向子節點的指標）：
葉子節點中，為了突出記錄，把(id, name, age)區分開來了，實際上是連在一起的，它們是構成一條記錄的整體。
而一個非聚集索引（以age為索引）的結構是：
除了年齡欄位本身之外，在該節點的葉子節點中，僅包含目前記錄的主鍵ID，而不包含完整記錄的資訊。需要透過id號到叢集索引中進行回表查詢才能取得整行記錄資料。
在InnoDB中，每張表必須有一個叢集索引，預設會根據主鍵建立。如果表中沒有主鍵，InnoDB會選擇一個適當的欄位作為叢集索引，如果找不到適當的資料列，則會使用一列隱藏的資料列DB_ROW_ID作為叢集索引。
非聚集索引中因為不含有完整的資料信息，查找完整的資料記錄需要回表，所以一次查詢操作實際上要做兩次索引查詢。如果每個索引查詢都需要進行兩次才能獲得結果，那麼這一定會導致效率下降，因為能夠減少一次查詢就應該減少一次。
以上面的age索引為例，它是一個非聚集索引，如果我想透過年齡查詢使用者的id，執行了下面一條語句：
1 |
select id from userinfo where age = 10; |
這種情況是否還有必要去回表？因為我只需要id的值，透過age這個索引就已經能拿到id了，如果還去回表一次不就做了無用的操作了嗎？實際上確實是不需要的。當輔助索引已經包含了所有查詢所需的資訊時，在索引查詢中就可以避免回表操作，這就是覆蓋索引。
聯合索引指的是同時對多列建立的索引，在建立聯合索引後，葉子節點會同時包含每個索引列的值，並且同時根據多列排序，這個排序和我們所理解的字典序類似。
例如同時對上面的姓名和年齡所建立的索引結構：
(name, age)都是簡寫，想不出十幾個名字。
每個葉子節點同時保存了所有的索引列，除此之外，還是只包含了主鍵id。
當對多列建立索引後，並不是只要包含了建立索引的列就能使用索引，索引的使用要遵循最左前綴匹配原則。
假設對列(A, B, C)建立索引，那麼只有下列場景能使用索引：
對列(A, B, C)/( A, C)或(A, B)進行查詢會符合索引，且對(C, A)或(B, C)來說不能使用索引。
通配符只能使用LIKE 'val%'形式，不能使用LIKE '%VAL%'，後者會導致全表掃描。
索引列不能運算，例如WHERE A 1 = 5這種場景會導致索引失效。
索引列不能包含範圍值查詢，如LIKE/BETWEEN/>/
索引列不能包含有NULL值。
新版本的MySQL（5.6以上）中引入了索引下推的機制：可以在索引遍歷過程中，對索引中包含的欄位先做判斷，直接過濾掉不符合條件的記錄，減少回表次數。
例如針對上面表中的(name, age)做聯合索引，正常情況下的查詢邏輯：
透過name找到對應的主鍵ID
根據id記錄的欄位來匹配age條件
這種做法會導致很多不必要的回表，例如表中存在(張三, 10 )和(張三, 15)兩筆記錄，此刻要查詢(張三, 20)的記錄。查詢時先透過張三定位到所有符合條件的主鍵ID，然後在叢集索引中遍歷滿足條件的行，看是否有符合age = 20的記錄。在實際情況中，沒有符合條件的記錄，因此這個回表過程可以看作是無功之舉。
索引下推的主要功能就是改善這一點，在聯合索引中，先透過姓名和年齡過濾掉不用回表的記錄，然後再回表查詢索引，減少回表次數。
唯一索引是一種不允許具有相同索引值的索引，系統在建立該索引時檢查是否有重複的鍵值，每次對更新或增加記錄時都會檢查這一點。主鍵索引就是唯一索引。
以上是MySQL中的叢集索引、非叢集索引、聯合索引和唯一索引是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
