關(guān)于MySQL的索引專題——認識索引
關(guān)于這個專題
想寫MySQL的索引專題是源于之前自己在學(xué)習MySQL索引時痛苦的經(jīng)歷，你在網(wǎng)上搜索關(guān)于MySQL的索引的文章，大多是支離破碎，沒有系統(tǒng)性的對知識點的羅列堆砌，文章中會說明你要如何如何做，但是很少涉及去講為什么要這么做，哪些不能做，很難對MySQL有一個系統(tǒng)性的認知，學(xué)習如果沒有系統(tǒng)性的話，就很難在實際的項目中靈活運用，出于此目的，自己就打算寫一個關(guān)于MySQL索引的專題系列，算是自己一個學(xué)習的總結(jié)，如果同時能幫到你那再好不過了。下面進入正題，我們先來了解一下什么是索引以及索引的類型。
認識索引
認識索引是什么東西非常關(guān)鍵，一個非常恰當?shù)谋扔骶褪菚哪夸涰撆c書的正文內(nèi)容之間的關(guān)系，為了方便查找書中的內(nèi)容，通過對內(nèi)容建立索引形成目錄。因此，首先你要明白的一點就是，索引它也是一個文件，它是要占據(jù)物理空間的。
比如對于MyISAM存儲引擎來說:
.frm后綴的文件存儲的是表結(jié)構(gòu)。
.myd后綴的文件存儲的是表數(shù)據(jù)。
.myi后綴的文件存儲的就是索引文件。
如下圖所示:
對于InnoDB 存儲引擎來說:
.frm后綴的文件存儲的是表結(jié)構(gòu)。
.ibd后綴的文件存放索引文件和數(shù)據(jù)(需要開啟innodb_file_per_table 參數(shù))
如下圖所示:
因此，當你對一張表建立索引時，索引文件的大小也會改變，當你數(shù)據(jù)表中的數(shù)據(jù)因為增刪改變化時，索引文件也會變化的，只不過MySQL會自動維護索引，這個過程不需要你介入，這也是為什么不恰當?shù)乃饕龝绊慚ySQL性能的原因。
總結(jié):
1. 索引是按照特定的數(shù)據(jù)結(jié)構(gòu)把數(shù)據(jù)表中的數(shù)據(jù)放在索引文件中，以便于快速查找;
2. 索引存在于磁盤中，會占據(jù)物理空間。
索引的類型
上面說到，索引文件時按照不同的數(shù)據(jù)結(jié)構(gòu)來存儲的，數(shù)據(jù)結(jié)構(gòu)的不同也產(chǎn)生了不同的索引類型，常見的索引類型包括:
- B-Tree索引
- 哈希索引
- 空間數(shù)據(jù)索引(R-Tree)
- 全文索引
下面做一一介紹:
1. B-Tree索引
B-Tree索引是最常用的一種索引，如果沒有指定特定的類型，那么多半就是B-Tree索引，事實上，很多搜索引擎使用的是它的變種B+Tree，這是對B-Tree的一個優(yōu)化，如果需要詳細了解，可以參考數(shù)據(jù)結(jié)構(gòu)方面的書籍，這里不做詳細探討。以下統(tǒng)稱為B-Tree索引。
絕大多數(shù)的存儲引擎，比如MyISAM和InnoDB都支持這種索引，因此說它是應(yīng)用最廣泛，最常用的一種索引方式，但是不同的存儲引擎在具體實現(xiàn)時會稍有不同，比如MyISAM會使用前綴壓縮的方式對索引進行壓縮，InnoDB則不會。
下圖展示了B-Tree索引是如何存儲被索引的數(shù)據(jù)的:
說明:
左圖是一個包含三列的數(shù)據(jù)表，右圖則展示了數(shù)據(jù)是如何被索引的。
可以看出B-Tree是對索引列是按照順序存儲的，每個葉子節(jié)點指向被索引的數(shù)據(jù)，這也是B-Tree索引支持范圍查找數(shù)據(jù)的原因。
2. 哈希索引
相比于B-Tree索引，哈希索引的實現(xiàn)就比較簡單了，它是基于哈希表來實現(xiàn)的，對于要索引的列，存儲引擎會計算出一一對應(yīng)的哈希碼，然后把哈希碼存放在哈希表中作為key，value值是指向該行數(shù)據(jù)的指針。
下圖是簡單的原理展示:
說明:
- 左邊紫色圖表示一個二列的數(shù)據(jù)表。
- 中間表示對fname列進行哈希索引，計算出哈希值。
- 右邊綠色圖表示把生成的哈希值存放于哈希表中。
當我們執(zhí)行以下查詢時:
- select * from testTable where fname = "mary";
MySQL會首先計算查詢條件mary的哈希值，然后到哈希表中去找該哈希值，如果找到了根據(jù)對應(yīng)的指針也就找到了需要尋找的數(shù)據(jù)行。
哈希表的優(yōu)勢與限制:
優(yōu)勢:
- 只需比對哈希值，因此速度非常快，性能優(yōu)勢明顯;
限制:
- 不支持任何范圍查詢，比如where price > 150，因為是基于哈希計算，支持等值比較。
- 哈希表是無序存儲的，因此索引數(shù)據(jù)無法用于排序。
- 主流存儲引擎不支持該類型，比如MyISAM和InnoDB。哈希索引只有Memory, NDB兩種引擎支持。
因此，哈希索引雖然速度快，但其實使用很受限，只適用于某些特殊的場合。
3. 空間數(shù)據(jù)索引(R-Tree)
空間索引可用于地理數(shù)據(jù)存儲，它需要GIS相關(guān)函數(shù)的支持，由于MySQL的GIS支持并不完善，所以該索引方式在MySQL中很少有人使用。
4. 全文索引
全文索引主要用于海量數(shù)據(jù)的搜索，比如淘寶或者京東對商品的搜索，你不可能使用like進行模糊匹配吧，MySQL從5.6開始支持InnoDB引擎的全文索引，功能沒有專業(yè)的搜索引擎比如Sphinx或Solr豐富，如果你的需求比較簡單，可以嘗試一下MySQL的全文索引，否則建議使用專業(yè)的搜索引擎。
總結(jié):
1. B-Tree索引使用最廣泛，主流引擎都支持。
2. 哈希索引性能高，適用于特殊場合。
3. R-Tree不常用。
4. 全文索引適用于海量數(shù)據(jù)的關(guān)鍵字模糊搜索。
索引和存儲引擎之間的關(guān)系
上面講述了索引有不同的類型，存儲引擎也有不同的類型，那么索引和存儲引擎之間有什么關(guān)系呢?
首先你需要知道，在MySQL中，索引是在存儲引擎中實現(xiàn)的，并不是所有的存儲引擎都支持所有的索引類型，比如哈希索引，MyISAM和InnoDB是不支持的;同樣，即使對于同一類型的索引，不同的存儲引擎實現(xiàn)的方式也可能是不同的，比如MyISAM和InnoDB對B-Tree索引，具體的實現(xiàn)是有差別的。
總結(jié):
1. 不同的存儲引擎可能支持不同的索引類型;
2. 不同的存儲引擎對同一中索引類型可能有不同的實現(xiàn)方式。
B-Tree索引與唯一索引，主鍵索引，普通索引的關(guān)系
最開始對B-Tree索引與唯一索引，主鍵索引，普通索引這幾種索引的關(guān)系很模糊，網(wǎng)上也沒搜索到相關(guān)的資料，以為他們的關(guān)系是并列的，其實并不是，B-Tree只是底層的算法實現(xiàn)，唯一索引，主鍵索引，普通索引都是基于B-Tree索引算法的，只不過又有各自的特點。
通過下圖也可看出這種關(guān)系:
至于唯一索引，主鍵索引，普通索引之間的區(qū)別，下面補充一下:
- 主鍵索引:數(shù)據(jù)列不允許重復(fù)，不允許為NULL.一個表只能有一個主鍵。
- 唯一索引:數(shù)據(jù)列不允許重復(fù)，允許為NULL值，一個表允許多個列創(chuàng)建唯一索引。
- 普通索引:基本的索引類型，沒有唯一性的限制，允許為NULL值。
總結(jié):
這篇文章先說到這里，目的主要是對MySQL的索引有個概念上的認識，以及了解索引的類型，索引和存儲引擎之間的關(guān)系，本專題會繼續(xù)更新，繼續(xù)對MySQL索引知識逐漸展開，如果你感興趣的話可以關(guān)注該專欄，以及順便動動手指關(guān)注一下我(^_^),希望本文對你有所幫助。
