亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

MySQL btree索引與hash索引區(qū)別

 更新時間:2020年09月24日 11:42:42   作者:Achilles_Heel  
這篇文章主要介紹了MySQL btree索引與hash索引區(qū)別,幫助大家更好的理解和學(xué)習(xí)MySQL索引的相關(guān)知識,感興趣的朋友可以了解下

在MySQL中,大多數(shù)索引(如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)都是在BTREE中存儲,但使用memory引擎可以選擇BTREE索引或者HASH索引,兩種不同類型的索引各自有其不同的使用范圍。

  • B樹索引具有范圍查找和前綴查找的能力,對于有N節(jié)點的B樹,檢索一條記錄的復(fù)雜度為O(LogN)。相當(dāng)于二分查找。
  • 哈希索引只能做等于查找,但是無論多大的Hash表,查找復(fù)雜度都是O(1)。

顯然,如果值的差異性大,并且以等值查找(=、 <、>、in)為主,Hash索引是更高效的選擇,它有O(1)的查找復(fù)雜度。
如果值的差異性相對較差,并且以范圍查找為主,B樹是更好的選擇,它支持范圍查找。

一、HASH索引

利用哈希函數(shù),計算存儲地址,檢索時不需要像Btree那樣,從根節(jié)點開始遍歷,逐級查找。

Hash 索引結(jié)構(gòu)的特殊性,其檢索效率非常高,索引的檢索可以一次定位,不像B-Tree 索引需要從根節(jié)點到枝節(jié)點,最后才能訪問到頁節(jié)點這樣多次的IO訪問,所以 Hash 索引的查詢效率要遠(yuǎn)高于 B-Tree 索引。

可能很多人又有疑問了,既然 Hash 索引的效率要比 B-Tree 高很多,為什么大家不都用 Hash 索引而還要使用 B-Tree 索引呢?任何事物都是有兩面性的,Hash 索引也一樣,雖然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也帶來了很多限制和弊端,主要有以下這些。

(1)Hash 索引僅僅能滿足”=”,”IN”和”<=>”查詢,不能使用范圍查詢(查詢范圍時 慢)。

由于 Hash 索引比較的是進(jìn)行 Hash 運(yùn)算之后的 Hash 值,所以它只能用于等值的過濾,不能用于基于范圍的過濾,因為經(jīng)過相應(yīng)的 Hash 算法處理之后的 Hash 值的大小關(guān)系,并不能保證和Hash運(yùn)算前完全一樣。

(2)Hash 索引無法被用來避免數(shù)據(jù)的排序操作。

由于 Hash 索引中存放的是經(jīng)過 Hash 計算之后的 Hash 值,而且Hash值的大小關(guān)系并不一定和 Hash 運(yùn)算前的鍵值完全一樣,所以數(shù)據(jù)庫無法利用索引的數(shù)據(jù)來避免任何排序運(yùn)算;

(3)Hash 索引不能利用部分索引鍵查詢。

對于組合索引,Hash 索引在計算 Hash 值的時候是組合索引鍵合并后再一起計算 Hash 值,而不是單獨(dú)計算 Hash 值,所以通過組合索引的前面一個或幾個索引鍵進(jìn)行查詢的時候,Hash 索引也無法被利用。

(4)Hash 索引在任何時候都不能避免表掃描。

前面已經(jīng)知道,Hash 索引是將索引鍵通過 Hash 運(yùn)算之后,將 Hash運(yùn)算結(jié)果的 Hash 值和所對應(yīng)的行指針信息存放于一個 Hash 表中,由于不同索引鍵存在相同 Hash 值,所以即使取滿足某個 Hash 鍵值的數(shù)據(jù)的記錄條數(shù),也無法從 Hash 索引中直接完成查詢,還是要通過訪問表中的實際數(shù)據(jù)進(jìn)行相應(yīng)的比較,并得到相應(yīng)的結(jié)果。

(5)Hash 索引遇到大量Hash值相等的情況后性能并不一定就會比B-Tree索引高。

對于選擇性比較低的索引鍵,如果創(chuàng)建 Hash 索引,那么將會存在大量記錄指針信息存于同一個 Hash 值相關(guān)聯(lián)。這樣要定位某一條記錄時就會非常麻煩,會浪費(fèi)多次表數(shù)據(jù)的訪問,而造成整體性能低下。

二、B+樹

  • b+樹的查找過程

如圖所示,如果要查找數(shù)據(jù)項29,那么首先會把磁盤塊1由磁盤加載到內(nèi)存,此時發(fā)生一次IO,在內(nèi)存中用二分查找確定29在17和35之間,鎖定磁盤塊1的P2指針,內(nèi)存時間因為非常短(相比磁盤的IO)可以忽略不計,通過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內(nèi)存,發(fā)生第二次IO,29在26和30之間,鎖定磁盤塊3的P2指針,通過指針加載磁盤塊8到內(nèi)存,發(fā)生第三次IO,同時內(nèi)存中做二分查找找到29,結(jié)束查詢,總計三次IO。真實的情況是,3層的b+樹可以表示上百萬的數(shù)據(jù),如果上百萬的數(shù)據(jù)查找只需要三次IO,性能提高將是巨大的,如果沒有索引,每個數(shù)據(jù)項都要發(fā)生一次IO,那么總共需要百萬次的IO,顯然成本非常非常高。

  • b+樹性質(zhì)

1.索引字段要盡量的?。?/strong>

通過上面的分析,我們知道IO次數(shù)取決于b+數(shù)的高度h,假設(shè)當(dāng)前數(shù)據(jù)表的數(shù)據(jù)為N,每個磁盤塊的數(shù)據(jù)項的數(shù)量是m,則有h=㏒(m+1)N,當(dāng)數(shù)據(jù)量N一定的情況下,m越大,h越??;而m = 磁盤塊的大小 / 數(shù)據(jù)項的大小,磁盤塊的大小也就是一個數(shù)據(jù)頁的大小,是固定的,如果數(shù)據(jù)項占的空間越小,數(shù)據(jù)項的數(shù)量越多,樹的高度越低。這就是為什么每個數(shù)據(jù)項,即索引字段要盡量的小,比如int占4字節(jié),要比bigint8字節(jié)少一半。這也是為什么b+樹要求把真實的數(shù)據(jù)放到葉子節(jié)點而不是內(nèi)層節(jié)點,一旦放到內(nèi)層節(jié)點,磁盤塊的數(shù)據(jù)項會大幅度下降,導(dǎo)致樹增高。當(dāng)數(shù)據(jù)項等于1時將會退化成線性表。

2.索引的最左匹配特性(即從左往右匹配):

當(dāng)b+樹的數(shù)據(jù)項是復(fù)合的數(shù)據(jù)結(jié)構(gòu),比如(name,age,sex)的時候,b+數(shù)是按照從左到右的順序來建立搜索樹的,比如當(dāng)(張三,20,F)這樣的數(shù)據(jù)來檢索的時候,b+樹會優(yōu)先比較name來確定下一步的所搜方向,如果name相同再依次比較age和sex,最后得到檢索的數(shù)據(jù);但當(dāng)(20,F)這樣的沒有name的數(shù)據(jù)來的時候,b+樹就不知道下一步該查哪個節(jié)點,因為建立搜索樹的時候name就是第一個比較因子,必須要先根據(jù)name來搜索才能知道下一步去哪里查詢。比如當(dāng)(張三,F)這樣的數(shù)據(jù)來檢索時,b+樹可以用name來指定搜索方向,但下一個字段age的缺失,所以只能把名字等于張三的數(shù)據(jù)都找到,然后再匹配性別是F的數(shù)據(jù)了, 這個是非常重要的性質(zhì),即索引的最左匹配特性。

以上就是MySQL btree索引與hash索引區(qū)別的詳細(xì)內(nèi)容,更多關(guān)于MySQL btree索引與hash索引的資料請關(guān)注腳本之家其它相關(guān)文章!

相關(guān)文章

  • MySQL中易被我們忽略的細(xì)節(jié)

    MySQL中易被我們忽略的細(xì)節(jié)

    這篇文章主要為大家介紹了幾處MySQL中易被我們誤會的地方,分享給大家,一來為了有趣,二來為了不讓自己踩坑。
    2016-07-07
  • 使用MySQL實現(xiàn)select?into臨時表的功能

    使用MySQL實現(xiàn)select?into臨時表的功能

    這篇文章主要介紹了使用MySQL實現(xiàn)select?into臨時表的功能,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教
    2022-09-09
  • mysql Key_buffer_size參數(shù)的優(yōu)化設(shè)置

    mysql Key_buffer_size參數(shù)的優(yōu)化設(shè)置

    mysql數(shù)據(jù)庫中有許多重要的參數(shù),其中mysql key_buffer_size是對MyISAM表性能影響最大的一個參數(shù),下面就讓我們一起來了解一下
    2014-12-12
  • 關(guān)于MySQL的時間進(jìn)位問題淺析

    關(guān)于MySQL的時間進(jìn)位問題淺析

    這篇文章主要給大家介紹了關(guān)于MySQL的時間進(jìn)位問題的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對大家學(xué)習(xí)或者使用MySQL具有一定的參考學(xué)習(xí)價值,需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-12-12
  • MySQL 5.6 GTID新特性實踐

    MySQL 5.6 GTID新特性實踐

    GTID(Global Transaction ID)是對于一個已提交事務(wù)的編號,并且是一個全局唯一的編號。下文給大家介紹MySQL 5.6 GTID新特性實踐,感興趣的朋友一起看看吧
    2016-10-10
  • MySQL定時器EVENT學(xué)習(xí)筆記

    MySQL定時器EVENT學(xué)習(xí)筆記

    本文為大家介紹下MySQL定時器EVENT,要使定時起作用 MySQL的常量GLOBAL event_scheduler必須為on或者是1,感興趣的朋友可以了解下
    2013-11-11
  • 詳解MySQL恢復(fù)psc文件記錄數(shù)為0的解決方案

    詳解MySQL恢復(fù)psc文件記錄數(shù)為0的解決方案

    這篇文章主要介紹了詳解MySQL恢復(fù)psc文件記錄數(shù)為0的解決方案,遇到這個問題的朋友,可以看一下。
    2016-11-11
  • mysql安裝報錯unknown variable mysqlx_port=0.0

    mysql安裝報錯unknown variable mysqlx_port=0.0

    本文主要介紹了mysql安裝報錯unknown variable mysqlx_port=0.0,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2024-06-06
  • 深入探究MySQL中使用where 1=1是否存在性能影響

    深入探究MySQL中使用where 1=1是否存在性能影響

    最近在項目中使用 mybatis 寫 SQL 使用了 where 1=1 來簡化多條件拼接的寫法,案例如下,借此聊聊多條件拼接的常見的一些寫法以及 where 1=1 是否存在性能影響,需要的朋友可以參考下
    2024-02-02
  • mysql中的utf8與utf8mb4存儲及區(qū)別

    mysql中的utf8與utf8mb4存儲及區(qū)別

    本文主要介紹了mysql中的utf8與utf8mb4存儲及區(qū)別,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2023-02-02

最新評論