如大家所知道的蒸播，Mysql目前主要有以下幾種索引類(lèi)型：FULLTEXT，HASH啥繁，BTREE菜职，RTREE。

那么旗闽，這幾種索引有什么功能和性能上的不同呢酬核？

FULLTEXT

即為全文索引，目前只有MyISAM引擎支持适室。其可以在CREATE TABLE 嫡意，ALTER TABLE ，CREATE INDEX 使用捣辆，不過(guò)目前只有 CHAR蔬螟、VARCHAR ，TEXT 列上可以創(chuàng)建全文索引汽畴。值得一提的是旧巾，在數(shù)據(jù)量較大時(shí)候，現(xiàn)將數(shù)據(jù)放入一個(gè)沒(méi)有全局索引的表中忍些，然后再用CREATE INDEX創(chuàng)建FULLTEXT索引鲁猩，要比先為一張表建立FULLTEXT然后再將數(shù)據(jù)寫(xiě)入的速度快很多。

全文索引并不是和MyISAM一起誕生的罢坝，它的出現(xiàn)是為了解決WHERE name LIKE “%word%"這類(lèi)針對(duì)文本的模糊查詢效率較低的問(wèn)題廓握。在沒(méi)有全文索引之前，這樣一個(gè)查詢語(yǔ)句是要進(jìn)行遍歷數(shù)據(jù)表操作的，可見(jiàn)隙券，在數(shù)據(jù)量較大時(shí)是極其的耗時(shí)的男应，如果沒(méi)有異步IO處理，進(jìn)程將被挾持娱仔，很浪費(fèi)時(shí)間沐飘，當(dāng)然這里不對(duì)異步IO作進(jìn)一步講解，想了解的童鞋拟枚，自行谷哥薪铜。

全文索引的使用方法并不復(fù)雜：

創(chuàng)建ALTER TABLE table ADD INDEX FULLINDEX USING FULLTEXT(cname1[,cname2…]);

使用SELECT * FROM table WHERE MATCH(cname1[,cname2…]) AGAINST ('word' MODE );

其中， MODE為搜尋方式（IN BOOLEAN MODE 恩溅，IN NATURAL LANGUAGE MODE ，IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION / WITH QUERY EXPANSION）谓娃。

關(guān)于這三種搜尋方式脚乡，愚安在這里也不多做交代，簡(jiǎn)單地說(shuō)滨达，就是奶稠，布爾模式，允許word里含一些特殊字符用于標(biāo)記一些具體的要求捡遍，如+表示一定要有锌订，-表示一定沒(méi)有，*表示通用匹配符画株，是不是想起了正則辆飘，類(lèi)似吧；自然語(yǔ)言模式谓传，就是簡(jiǎn)單的單詞匹配蜈项；含表達(dá)式的自然語(yǔ)言模式，就是先用自然語(yǔ)言模式處理续挟，對(duì)返回的結(jié)果紧卒，再進(jìn)行表達(dá)式匹配。

對(duì)搜索引擎稍微有點(diǎn)了解的同學(xué)诗祸，肯定知道分詞這個(gè)概念跑芳，F(xiàn)ULLTEXT索引也是按照分詞原理建立索引的。西文中直颅，大部分為字母文字博个，分詞可以很方便的按照空格進(jìn)行分割。但很明顯际乘，中文不能按照這種方式進(jìn)行分詞坡倔。那又怎么辦呢？這個(gè)向大家介紹一個(gè)Mysql的中文分詞插件Mysqlcft，有了它罪塔，就可以對(duì)中文進(jìn)行分詞投蝉，想了解的同學(xué)請(qǐng)移步Mysqlcft，當(dāng)然還有其他的分詞插件可以使用征堪。

HASH

Hash這個(gè)詞瘩缆，可以說(shuō)，自打我們開(kāi)始碼的那一天起佃蚜，就開(kāi)始不停地見(jiàn)到和使用到了庸娱。其實(shí)，hash就是一種（key=>value）形式的鍵值對(duì)谐算，如數(shù)學(xué)中的函數(shù)映射熟尉，允許多個(gè)key對(duì)應(yīng)相同的value，但不允許一個(gè)key對(duì)應(yīng)多個(gè)value洲脂。正是由于這個(gè)特性斤儿，hash很適合做索引，為某一列或幾列建立hash索引，就會(huì)利用這一列或幾列的值通過(guò)一定的算法計(jì)算出一個(gè)hash值，對(duì)應(yīng)一行或幾行數(shù)據(jù)（這里在概念上和函數(shù)映射有區(qū)別吓歇，不要混淆）。在java語(yǔ)言中陕贮，每個(gè)類(lèi)都有自己的hashcode()方法，沒(méi)有顯示定義的都繼承自object類(lèi)潘飘，該方法使得每一個(gè)對(duì)象都是唯一的肮之，在進(jìn)行對(duì)象間equal比較，和序列化傳輸中起到了很重要的作用福也。hash的生成方法有很多種局骤，足可以保證hash碼的唯一性，例如在MongoDB中暴凑，每一個(gè)document都有系統(tǒng)為其生成的唯一的objectID（包含時(shí)間戳峦甩，主機(jī)散列值，進(jìn)程PID现喳，和自增ID）也是一種hash的表現(xiàn)凯傲。額，我好像扯遠(yuǎn)了-_-!

由于hash索引可以一次定位嗦篱，不需要像樹(shù)形索引那樣逐層查找,因此具有極高的效率冰单。那為什么還需要其他的樹(shù)形索引呢？

在這里愚安就不自己總結(jié)了灸促。引用下園子里其他大神的文章：來(lái)自 14的路 的MySQL的btree索引和hash索引的區(qū)別

（1）Hash 索引僅僅能滿足"=","IN"和"<=>"查詢诫欠，不能使用范圍查詢涵卵。
由于 Hash 索引比較的是進(jìn)行 Hash 運(yùn)算之后的 Hash 值，所以它只能用于等值的過(guò)濾荒叼，不能用于基于范圍的過(guò)濾轿偎，因?yàn)榻?jīng)過(guò)相應(yīng)的 Hash 算法處理之后的 Hash 值的大小關(guān)系，并不能保證和Hash運(yùn)算前完全一樣被廓。
（2）Hash 索引無(wú)法被用來(lái)避免數(shù)據(jù)的排序操作坏晦。
由于 Hash 索引中存放的是經(jīng)過(guò) Hash 計(jì)算之后的 Hash 值，而且Hash值的大小關(guān)系并不一定和 Hash 運(yùn)算前的鍵值完全一樣嫁乘，所以數(shù)據(jù)庫(kù)無(wú)法利用索引的數(shù)據(jù)來(lái)避免任何排序運(yùn)算昆婿；
（3）Hash 索引不能利用部分索引鍵查詢。
對(duì)于組合索引蜓斧，Hash 索引在計(jì)算 Hash 值的時(shí)候是組合索引鍵合并后再一起計(jì)算 Hash 值仓蛆，而不是單獨(dú)計(jì)算 Hash 值，所以通過(guò)組合索引的前面一個(gè)或幾個(gè)索引鍵進(jìn)行查詢的時(shí)候挎春，Hash 索引也無(wú)法被利用多律。
（4）Hash 索引在任何時(shí)候都不能避免表掃描。
前面已經(jīng)知道搂蜓，Hash 索引是將索引鍵通過(guò) Hash 運(yùn)算之后，將 Hash運(yùn)算結(jié)果的 Hash 值和所對(duì)應(yīng)的行指針信息存放于一個(gè) Hash 表中辽装，由于不同索引鍵存在相同 Hash 值帮碰，所以即使取滿足某個(gè) Hash 鍵值的數(shù)據(jù)的記錄條數(shù)，也無(wú)法從 Hash 索引中直接完成查詢拾积，還是要通過(guò)訪問(wèn)表中的實(shí)際數(shù)據(jù)進(jìn)行相應(yīng)的比較殉挽，并得到相應(yīng)的結(jié)果。
（5）Hash 索引遇到大量Hash值相等的情況后性能并不一定就會(huì)比B-Tree索引高拓巧。
對(duì)于選擇性比較低的索引鍵斯碌，如果創(chuàng)建 Hash 索引，那么將會(huì)存在大量記錄指針信息存于同一個(gè) Hash 值相關(guān)聯(lián)肛度。這樣要定位某一條記錄時(shí)就會(huì)非常麻煩傻唾，會(huì)浪費(fèi)多次表數(shù)據(jù)的訪問(wèn)，而造成整體性能低下承耿。

愚安我稍作補(bǔ)充冠骄，講一下HASH索引的過(guò)程，順便解釋下上面的第4,5條：

當(dāng)我們?yōu)槟骋涣谢蚰硯琢薪ash索引時(shí)（目前就只有MEMORY引擎顯式地支持這種索引）加袋，會(huì)在硬盤(pán)上生成類(lèi)似如下的文件：

hash值即為通過(guò)特定算法由指定列數(shù)據(jù)計(jì)算出來(lái)凛辣，磁盤(pán)地址即為所在數(shù)據(jù)行存儲(chǔ)在硬盤(pán)上的地址（也有可能是其他存儲(chǔ)地址，其實(shí)MEMORY會(huì)將hash表導(dǎo)入內(nèi)存）职烧。

這樣扁誓，當(dāng)我們進(jìn)行WHERE age = 18 時(shí)防泵，會(huì)將18通過(guò)相同的算法計(jì)算出一個(gè)hash值==>在hash表中找到對(duì)應(yīng)的儲(chǔ)存地址==>根據(jù)存儲(chǔ)地址取得數(shù)據(jù)。

所以蝗敢，每次查詢時(shí)都要遍歷hash表捷泞，直到找到對(duì)應(yīng)的hash值，如（4）前普，數(shù)據(jù)量大了之后肚邢，hash表也會(huì)變得龐大起來(lái)，性能下降拭卿，遍歷耗時(shí)增加骡湖，如（5）。

BTREE

BTREE索引就是一種將索引值按一定的算法峻厚，存入一個(gè)樹(shù)形的數(shù)據(jù)結(jié)構(gòu)中响蕴，相信學(xué)過(guò)數(shù)據(jù)結(jié)構(gòu)的童鞋都對(duì)當(dāng)初學(xué)習(xí)二叉樹(shù)這種數(shù)據(jù)結(jié)構(gòu)的經(jīng)歷記憶猶新，反正愚安我當(dāng)時(shí)為了軟考可是被這玩意兒好好地折騰了一番惠桃，不過(guò)那次考試好像沒(méi)怎么考這個(gè)浦夷。如二叉樹(shù)一樣，每次查詢都是從樹(shù)的入口root開(kāi)始辜王，依次遍歷node劈狐，獲取leaf。

BTREE在MyISAM里的形式和Innodb稍有不同

在 Innodb里呐馆，有兩種形態(tài)：一是primary key形態(tài)肥缔，其leaf node里存放的是數(shù)據(jù)，而且不僅存放了索引鍵的數(shù)據(jù)汹来，還存放了其他字段的數(shù)據(jù)续膳。二是secondary index，其leaf node和普通的BTREE差不多收班，只是還存放了指向主鍵的信息.

而在MyISAM里坟岔，主鍵和其他的并沒(méi)有太大區(qū)別。不過(guò)和Innodb不太一樣的地方是在MyISAM里摔桦，leaf node里存放的不是主鍵的信息社付，而是指向數(shù)據(jù)文件里的對(duì)應(yīng)數(shù)據(jù)行的信息.

RTREE

RTREE在mysql很少使用，僅支持geometry數(shù)據(jù)類(lèi)型酣溃，支持該類(lèi)型的存儲(chǔ)引擎只有MyISAM瘦穆、BDb、InnoDb赊豌、NDb扛或、Archive幾種。

相對(duì)于BTREE碘饼，RTREE的優(yōu)勢(shì)在于范圍查找.

各種索引的使用情況

（1）對(duì)于BTREE這種Mysql默認(rèn)的索引類(lèi)型熙兔，具有普遍的適用性

（2）由于FULLTEXT對(duì)中文支持不是很好悲伶，在沒(méi)有插件的情況下，最好不要使用住涉。其實(shí)麸锉，一些小的博客應(yīng)用，只需要在數(shù)據(jù)采集時(shí)舆声，為其建立關(guān)鍵字列表花沉，通過(guò)關(guān)鍵字索引，也是一個(gè)不錯(cuò)的方法媳握，至少愚安我是經(jīng)常這么做的碱屁。

（3）對(duì)于一些搜索引擎級(jí)別的應(yīng)用來(lái)說(shuō)，F(xiàn)ULLTEXT同樣不是一個(gè)好的處理方法蛾找，Mysql的全文索引建立的文件還是比較大的娩脾，而且效率不是很高，即便是使用了中文分詞插件打毛，對(duì)中文分詞支持也只是一般柿赊。真要碰到這種問(wèn)題，Apache的Lucene或許是你的選擇幻枉。

（4）正是因?yàn)閔ash表在處理較小數(shù)據(jù)量時(shí)具有無(wú)可比擬的素的優(yōu)勢(shì)碰声，所以hash索引很適合做緩存（內(nèi)存數(shù)據(jù)庫(kù)）。如mysql數(shù)據(jù)庫(kù)的內(nèi)存版本Memsql熬甫，使用量很廣泛的緩存工具M(jìn)encached奥邮，NoSql數(shù)據(jù)庫(kù)redis等，都使用了hash索引這種形式罗珍。當(dāng)然，不想學(xué)習(xí)這些東西的話Mysql的MEMORY引擎也是可以滿足這種需求的脚粟。

（5）至于RTREE覆旱，愚安我至今還沒(méi)有使用過(guò)，它具體怎么樣核无，我就不知道了扣唱。有RTREE使用經(jīng)歷的同學(xué)，到時(shí)可以交流下团南！

轉(zhuǎn)發(fā)地址：https://www.cnblogs.com/yuan-shuai/p/3225417.html