索引根據底層實作可分為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中文網其他相關文章!