1. 程式人生 > >索引的幾種使用方式

索引的幾種使用方式

查找 浪費 相對 掃描 遇到 l數據庫 系統 需求 mem

HASH

Hash這個詞,可以說,自打我們開始碼的那一天起,就開始不停地見到和使用到了。其實,hash就是一種(key=>value)形式的鍵值對,如數學中的函數映射,允許多個key對應相同的value,但不允許一個key對應多個value。正是由於這個特性,hash很適合做索引,為某一列或幾列建立hash索引,就會利用這一列或幾列的值通過一定的算法計算出一個hash值,對應一行或幾行數據(這裏在概念上和函數映射有區別,不要混淆)。在java語言中,每個類都有自己的hashcode()方法,沒有顯示定義的都繼承自object類,該方法使得每一個對象都是唯一的,在進行對象間equal比較,和序列化傳輸中起到了很重要的作用。hash的生成方法有很多種,足可以保證hash碼的唯一性,例如在MongoDB中,每一個document都有系統為其生成的唯一的objectID(包含時間戳,主機散列值,進程PID,和自增ID)也是一種hash的表現。額,我好像扯遠了-_-!

由於hash索引可以一次定位,不需要像樹形索引那樣逐層查找,因此具有極高的效率。那為什麽還需要其他的樹形索引呢?

在這裏就不自己總結了。引用下園子裏其他大神的文章:來自 14的路 的MySQL的btree索引和hash索引的區別

(1)Hash 索引僅僅能滿足"=","IN"和"<=>"查詢,不能使用範圍查詢。
由於 Hash 索引比較的是進行 Hash 運算之後的 Hash 值,所以它只能用於等值的過濾,不能用於基於範圍的過濾,因為經過相應的 Hash 算法處理之後的 Hash 值的大小關系,並不能保證和Hash運算前完全一樣。
(2)Hash 索引無法被用來避免數據的排序操作。
由於 Hash 索引中存放的是經過 Hash 計算之後的 Hash 值,而且Hash值的大小關系並不一定和 Hash 運算前的鍵值完全一樣,所以數據庫無法利用索引的數據來避免任何排序運算;
(3)Hash 索引不能利用部分索引鍵查詢。
對於組合索引,Hash 索引在計算 Hash 值的時候是組合索引鍵合並後再一起計算 Hash 值,而不是單獨計算 Hash 值,所以通過組合索引的前面一個或幾個索引鍵進行查詢的時候,Hash 索引也無法被利用。
(4)Hash 索引在任何時候都不能避免表掃描。
前面已經知道,Hash 索引是將索引鍵通過 Hash 運算之後,將 Hash運算結果的 Hash 值和所對應的行指針信息存放於一個 Hash 表中,由於不同索引鍵存在相同 Hash 值,所以即使取滿足某個 Hash 鍵值的數據的記錄條數,也無法從 Hash 索引中直接完成查詢,還是要通過訪問表中的實際數據進行相應的比較,並得到相應的結果。
(5)Hash 索引遇到大量Hash值相等的情況後性能並不一定就會比B-Tree索引高。
對於選擇性比較低的索引鍵,如果創建 Hash 索引,那麽將會存在大量記錄指針信息存於同一個 Hash 值相關聯。這樣要定位某一條記錄時就會非常麻煩,會浪費多次表數據的訪問,而造成整體性能低下。

我稍作補充,講一下HASH索引的過程,順便解釋下上面的第4,5條:

當我們為某一列或某幾列建立hash索引時(目前就只有MEMORY引擎顯式地支持這種索引),會在硬盤上生成類似如下的文件:

hash值

存儲地址

1db54bc745a1

77#45b5

4bca452157d4

76#4556,77#45cc…

hash值即為通過特定算法由指定列數據計算出來,磁盤地址即為所在數據行存儲在硬盤上的地址(也有可能是其他存儲地址,其實MEMORY會將hash表導入內存)。

這樣,當我們進行WHERE age = 18 時,會將18通過相同的算法計算出一個hash值==>在hash表中找到對應的儲存地址==>根據存儲地址取得數據。

所以,每次查詢時都要遍歷hash表,直到找到對應的hash值,如(4),數據量大了之後,hash表也會變得龐大起來,性能下降,遍歷耗時增加,如(5)。

BTREE

BTREE索引就是一種將索引值按一定的算法,存入一個樹形的數據結構中,相信學過數據結構的童鞋都對當初學習二叉樹這種數據結構的經歷記憶猶新,反正我當時為了軟考可是被這玩意兒好好地折騰了一番,不過那次考試好像沒怎麽考這個。如二叉樹一樣,每次查詢都是從樹的入口root開始,依次遍歷node,獲取leaf。

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

在 Innodb裏,有兩種形態:一是primary key形態,其leaf node裏存放的是數據,而且不僅存放了索引鍵的數據,還存放了其他字段的數據。二是secondary index,其leaf node和普通的BTREE差不多,只是還存放了指向主鍵的信息.

而在MyISAM裏,主鍵和其他的並沒有太大區別。不過和Innodb不太一樣的地方是在MyISAM裏,leaf node裏存放的不是主鍵的信息,而是指向數據文件裏的對應數據行的信息.

RTREE

RTREE在mysql很少使用,僅支持geometry數據類型,支持該類型的存儲引擎只有MyISAM、BDb、InnoDb、NDb、Archive幾種。

相對於BTREE,RTREE的優勢在於範圍查找.

各種索引的使用情況

(1)對於BTREE這種Mysql默認的索引方式,具有普遍的適用性

(2)由於FULLTEXT對中文支持不是很好,在沒有插件的情況下,最好不要使用。其實,一些小的博客應用,只需要在數據采集時,為其建立關鍵字列表,通過關鍵字索引,也是一個不錯的方法,至少我是經常這麽做的。

(3)對於一些搜索引擎級別的應用來說,FULLTEXT同樣不是一個好的處理方法,Mysql的全文索引建立的文件還是比較大的,而且效率不是很高,即便是使用了中文分詞插件,對中文分詞支持也只是一般。真要碰到這種問題,Apache的Lucene或許是你的選擇。

(4)正是因為hash表在處理較小數據量時具有無可比擬的素的優勢,所以hash索引很適合做緩存(內存數據庫)。如mysql數據庫的內存版本Memsql,使用量很廣泛的緩存工具Mencached,NoSql數據庫redis等,都使用了hash索引這種形式。當然,不想學習這些東西的話Mysql的MEMORY引擎也是可以滿足這種需求的。

(5)至於RTREE,至今還沒有使用過,它具體怎麽樣,我就不知道了。有RTREE使用經歷的同學,到時可以交流下!

索引的幾種使用方式