MySQL索引原理

mysql官方對索引定義：是儲存引擎用於快速查詢記錄的一種資料結構。需要額外開闢空間和資料維護工作。

所以要想理解mysql的索引原理需要了解一些資料結構的理論知識

二叉搜尋樹的特點是：每個節點的左側子節點小於父節點，父節點又小於右側子節點。如圖所示：

假如我們需要執行select * from t where col2 = 89這條語句

如果沒有索引的情況下，需要對錶進行逐行查詢，而資料庫中的表資料均是放在磁碟中，每次查詢都需要與磁碟進行一次io互動，所以要找到col=2的資料就需要進行6次磁碟io，這種方式效能是比較差的。

如果mysql索引使用了二叉樹這種資料結構，執行上面的sql語句需要從根節點起開始查詢，發現要找的值89比34大，需要向右側節點查詢，這樣經歷兩次磁碟io就能找到，89這條資料了

那為什麼最終沒有選擇二叉樹作為索引結構呢，原因是有些場景不太適合，假如以col1作為索引列，而這一列的資料是依次遞增的，最終發現二叉樹會單邊增長，如果要查詢col1=6的資料，依然會進行6次磁碟io，因此二叉樹不太適合單邊增長的序列字段

紅黑樹又叫二叉平衡樹，同樣以單邊依次增長的資料為例，我們發現如果葉子節點的一邊高度比另一邊高度大2的話，它會有個自旋的動作，自動平衡高度，這樣就解決了二叉樹不太適合單邊增長的序列欄位的問題

那為什麼mysql依然沒有選擇紅黑樹為索引的資料結構呢？

如果說表的資料量特別大的話，那麼以紅黑樹為索引字段，它的高度會特別高，如果查詢最底層的資料依然會進行多次磁碟io，查詢速度依然沒有多大提公升

b樹特點：

索引值和data資料分布在整棵樹結構中

每個節點可以存放多個索引值及對應的data資料

樹節點中的多個索引值從左到右公升序排列

我們發現雖然b樹的每個節點可以儲存多個索引值，大小預設16k，但是如果需要獲取多個欄位的值，data的大小就會變大，每個節點儲存的索引元素就會變少，一定程度上樹的高度也是不可控的

b+樹的特點：

非葉子節點不儲存data資料，只儲存索引值，這樣便於儲存更多的索引值

葉子節點包含了所有的索引值和data資料

葉子節點用指標連線，提高區間的訪問效能

相比於b樹，b+樹非葉子節點不儲存data資料，只儲存索引值，那麼它橫向就會儲存更多的索引元素，b+樹的高度會遠遠小於b樹，即使3層高度的b+樹，就能支援千萬級別的資料

而mysql在b+樹的基礎上又作了一層優化，把葉子節點的連線指標改為雙向，方便col1>= 18，col2<=50這種查詢

mysql也支援hash索引，把索引值經過hash運算生成hashcode能快速定位到磁碟中的資料，

hash索引可以方便的提供等值查詢，但是對於範圍查詢就需要全表掃瞄了

myisam索引檔案和資料檔案是分離的(非聚集)，索引儲存在myi檔案中，表資料儲存在myd檔案中，

而這種儲存引擎對應的索引結構就如上圖，它的data元素中儲存的是資料所在行的磁碟檔案指標，

搜尋過程：假如where條件col1=49，首先會在myi檔案中找到對應資料的磁碟檔案指標，然後根據指標在myd檔案中快速定位資料，把整行資料載入到記憶體中

從圖中不難看出，根據葉子節點的內容，索引型別分為主鍵索引和非主鍵索引。

主鍵索引的葉子節點存的是整行資料。在innodb裡，主鍵索引也被稱為聚簇索引。

非主鍵索引的葉子節點內容是主鍵的值。在innodb裡，非主鍵索引也被稱為二級索引。

根據上面的索引結構說明，我們來討論乙個問題：基於主鍵索引和普通索引的查詢有什麼區別？

也就是說，基於非主鍵索引的查詢需要多掃瞄一棵索引樹。因此，我們在應用中應該盡量使用主鍵查詢。

innodb儲存引擎的表資料及索引均儲存在ibd檔案中，它的索引結構與myisam儲存引擎區別在於data元素儲存的非索引欄位的所有資料

為什麼innodb表必須有主鍵，並且推薦使用整型的自增主鍵？

因為innodb表資料儲存在data元素中，且二級索引依賴於主鍵索引，推薦自增整形的自增主鍵，假如使用uuid作為主鍵，而查詢過程中需要大量比較大小的操作，整形的效率肯定比字串高，且整形的大小比字串小，乙個節點能儲存更多的索引值，而自增是由於b+樹的特性是從左到右依次遞增的