mysql數(shù)據(jù)索引詳細介紹_第1頁
mysql數(shù)據(jù)索引詳細介紹_第2頁
mysql數(shù)據(jù)索引詳細介紹_第3頁
mysql數(shù)據(jù)索引詳細介紹_第4頁
mysql數(shù)據(jù)索引詳細介紹_第5頁
已閱讀5頁,還剩8頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認(rèn)領(lǐng)

文檔簡介

歡迎閱讀本文檔,希望本文檔能對您有所幫助!歡迎閱讀本文檔,希望本文檔能對您有所幫助!歡迎閱讀本文檔,希望本文檔能對您有所幫助!歡迎閱讀本文檔,希望本文檔能對您有所幫助!歡迎閱讀本文檔,希望本文檔能對您有所幫助!歡迎閱讀本文檔,希望本文檔能對您有所幫助!mysql數(shù)據(jù)索引詳細介紹索引是一種數(shù)據(jù)結(jié)構(gòu),用于幫助我們在大量數(shù)據(jù)中快速定位到我們想要查找的數(shù)據(jù)。索引最形象的比喻就是圖書的目錄了。注意這里的大量,數(shù)據(jù)量大了索引才顯得有意義,如果我想要在[1,2,3,4]中找到4這個數(shù)據(jù),直接對全數(shù)據(jù)檢索也很快,沒有必要費力氣建索引再去查找。索引在MySQL數(shù)據(jù)庫中分三類:B+樹索引Hash索引全文索引我們今天要介紹的是工作開發(fā)中最常接觸到的InnoDB存儲引擎中的B+樹索引。要介紹B+樹索引,就不得不提二叉查找樹,平衡二叉樹和B樹這三種數(shù)據(jù)結(jié)構(gòu)。B+樹就是從他們仨演化來的。二叉查找樹首先,讓我們先看一張圖:從圖中可以看到,我們?yōu)閡ser表(用戶信息表)建立了一個二叉查找樹的索引。圖中的圓為二叉查找樹的節(jié)點,節(jié)點中存儲了鍵(key)和數(shù)據(jù)(data)。鍵對應(yīng)user表中的id,數(shù)據(jù)對應(yīng)user表中的行數(shù)據(jù)。二叉查找樹的特點就是任何節(jié)點的左子節(jié)點的鍵值都小于當(dāng)前節(jié)點的鍵值,右子節(jié)點的鍵值都大于當(dāng)前節(jié)點的鍵值。頂端的節(jié)點我們稱為根節(jié)點,沒有子節(jié)點的節(jié)點我們稱之為葉節(jié)點。如果我們需要查找id=12的用戶信息,利用我們創(chuàng)建的二叉查找樹索引,查找流程如下:將根節(jié)點作為當(dāng)前節(jié)點,把12與當(dāng)前節(jié)點的鍵值10比較,12大于10,接下來我們把當(dāng)前節(jié)點的右子節(jié)點作為當(dāng)前節(jié)點。繼續(xù)把12和當(dāng)前節(jié)點的鍵值13比較,發(fā)現(xiàn)12小于13,把當(dāng)前節(jié)點的左子節(jié)點作為當(dāng)前節(jié)點。把12和當(dāng)前節(jié)點的鍵值12對比,12等于12,滿足條件,我們從當(dāng)前節(jié)點中取出data,即id=12,name=xm。利用二叉查找樹我們只需要3次即可找到匹配的數(shù)據(jù)。如果在表中一條條的查找的話,我們需要6次才能找到。平衡二叉樹上面我們講解了利用二叉查找樹可以快速的找到數(shù)據(jù)。但是,如果上面的二叉查找樹是這樣的構(gòu)造:這個時候可以看到我們的二叉查找樹變成了一個鏈表。如果我們需要查找id=17的用戶信息,我們需要查找7次,也就相當(dāng)于全表掃描了。導(dǎo)致這個現(xiàn)象的原因其實是二叉查找樹變得不平衡了,也就是高度太高了,從而導(dǎo)致查找效率的不穩(wěn)定。為了解決這個問題,我們需要保證二叉查找樹一直保持平衡,就需要用到平衡二叉樹了。平衡二叉樹又稱AVL樹,在滿足二叉查找樹特性的基礎(chǔ)上,要求每個節(jié)點的左右子樹的高度差不能超過1。下面是平衡二叉樹和非平衡二叉樹的對比:由平衡二叉樹的構(gòu)造我們可以發(fā)現(xiàn)第一張圖中的二叉樹其實就是一棵平衡二叉樹。平衡二叉樹保證了樹的構(gòu)造是平衡的,當(dāng)我們插入或刪除數(shù)據(jù)導(dǎo)致不滿足平衡二叉樹不平衡時,平衡二叉樹會進行調(diào)整樹上的節(jié)點來保持平衡。具體的調(diào)整方式這里就不介紹了。平衡二叉樹相比于二叉查找樹來說,查找效率更穩(wěn)定,總體的查找速度也更快。B樹因為內(nèi)存的易失性。一般情況下,我們都會選擇將user表中的數(shù)據(jù)和索引存儲在磁盤這種外圍設(shè)備中。但是和內(nèi)存相比,從磁盤中讀取數(shù)據(jù)的速度會慢上百倍千倍甚至萬倍,所以,我們應(yīng)當(dāng)盡量減少從磁盤中讀取數(shù)據(jù)的次數(shù)。另外,從磁盤中讀取數(shù)據(jù)時,都是按照磁盤塊來讀取的,并不是一條一條的讀。如果我們能把盡量多的數(shù)據(jù)放進磁盤塊中,那一次磁盤讀取操作就會讀取更多數(shù)據(jù),那我們查找數(shù)據(jù)的時間也會大幅度降低。如果我們用樹這種數(shù)據(jù)結(jié)構(gòu)作為索引的數(shù)據(jù)結(jié)構(gòu),那我們每查找一次數(shù)據(jù)就需要從磁盤中讀取一個節(jié)點,也就是我們說的一個磁盤塊。我們都知道平衡二叉樹可是每個節(jié)點只存儲一個鍵值和數(shù)據(jù)的。那說明什么?說明每個磁盤塊僅僅存儲一個鍵值和數(shù)據(jù)!那如果我們要存儲海量的數(shù)據(jù)呢?可以想象到二叉樹的節(jié)點將會非常多,高度也會極其高,我們查找數(shù)據(jù)時也會進行很多次磁盤IO,我們查找數(shù)據(jù)的效率將會極低!為了解決平衡二叉樹的這個弊端,我們應(yīng)該尋找一種單個節(jié)點可以存儲多個鍵值和數(shù)據(jù)的平衡樹。也就是我們接下來要說的B樹。B樹(BalanceTree)即為平衡樹的意思,下圖即是一棵B樹:圖中的p節(jié)點為指向子節(jié)點的指針,二叉查找樹和平衡二叉樹其實也有,因為圖的美觀性,被省略了。圖中的每個節(jié)點稱為頁,頁就是我們上面說的磁盤塊,在MySQL中數(shù)據(jù)讀取的基本單位都是頁,所以我們這里叫做頁更符合MySQL中索引的底層數(shù)據(jù)結(jié)構(gòu)。從上圖可以看出,B樹相對于平衡二叉樹,每個節(jié)點存儲了更多的鍵值(key)和數(shù)據(jù)(data),并且每個節(jié)點擁有更多的子節(jié)點,子節(jié)點的個數(shù)一般稱為階,上述圖中的B樹為3階B樹,高度也會很低。基于這個特性,B樹查找數(shù)據(jù)讀取磁盤的次數(shù)將會很少,數(shù)據(jù)的查找效率也會比平衡二叉樹高很多。假如我們要查找id=28的用戶信息,那么我們在上圖B樹中查找的流程如下:先找到根節(jié)點也就是頁1,判斷28在鍵值17和35之間,那么我們根據(jù)頁1中的指針p2找到頁3。將28和頁3中的鍵值相比較,28在26和30之間,我們根據(jù)頁3中的指針p2找到頁8。將28和頁8中的鍵值相比較,發(fā)現(xiàn)有匹配的鍵值28,鍵值28對應(yīng)的用戶信息為(28,bv)。B+樹B+樹是對B樹的進一步優(yōu)化。讓我們先來看下B+樹的結(jié)構(gòu)圖:根據(jù)上圖我們來看下B+樹和B樹有什么不同:①B+樹非葉子節(jié)點上是不存儲數(shù)據(jù)的,僅存儲鍵值,而B樹節(jié)點中不僅存儲鍵值,也會存儲數(shù)據(jù)。之所以這么做是因為在數(shù)據(jù)庫中頁的大小是固定的,InnoDB中頁的默認(rèn)大小是16KB。如果不存儲數(shù)據(jù),那么就會存儲更多的鍵值,相應(yīng)的樹的階數(shù)(節(jié)點的子節(jié)點樹)就會更大,樹就會更矮更胖,如此一來我們查找數(shù)據(jù)進行磁盤的IO次數(shù)又會再次減少,數(shù)據(jù)查詢的效率也會更快。另外,B+樹的階數(shù)是等于鍵值的數(shù)量的,如果我們的B+樹一個節(jié)點可以存儲1000個鍵值,那么3層B+樹可以存儲1000times;1000times;1000=10億個數(shù)據(jù)。一般根節(jié)點是常駐內(nèi)存的,所以一般我們查找10億數(shù)據(jù),只需要2次磁盤IO。②因為B+樹索引的所有數(shù)據(jù)均存儲在葉子節(jié)點,而且數(shù)據(jù)是按照順序排列的。那么B+樹使得范圍查找,排序查找,分組查找以及去重查找變得異常簡單。而B樹因為數(shù)據(jù)分散在各個節(jié)點,要實現(xiàn)這一點是很不容易的。有心的讀者可能還發(fā)現(xiàn)上圖B+樹中各個頁之間是通過雙向鏈表連接的,葉子節(jié)點中的數(shù)據(jù)是通過單向鏈表連接的。其實上面的B樹我們也可以對各個節(jié)點加上鏈表。這些不是它們之前的區(qū)別,是因為在MySQL的InnoDB存儲引擎中,索引就是這樣存儲的。也就是說上圖中的B+樹索引就是InnoDB中B+樹索引真正的實現(xiàn)方式,準(zhǔn)確的說應(yīng)該是聚集索引(聚集索引和非聚集索引下面會講到)。通過上圖可以看到,在InnoDB中,我們通過數(shù)據(jù)頁之間通過雙向鏈表連接以及葉子節(jié)點中數(shù)據(jù)之間通過單向鏈表連接的方式可以找到表中所有的數(shù)據(jù)。MyISAM中的B+樹索引實現(xiàn)與InnoDB中的略有不同。在MyISAM中,B+樹索引的葉子節(jié)點并不存儲數(shù)據(jù),而是存儲數(shù)據(jù)的文件地址。聚集索引VS非聚集索引在上節(jié)介紹B+樹索引的時候,我們提到了圖中的索引其實是聚集索引的實現(xiàn)方式。那什么是聚集索引呢?在MySQL中,B+樹索引按照存儲方式的不同分為聚集索引和非聚集索引。這里我們著重介紹InnoDB中的聚集索引和非聚集索引:①聚集索引(聚簇索引):以InnoDB作為存儲引擎的表,表中的數(shù)據(jù)都會有一個主鍵,即使你不創(chuàng)建主鍵,系統(tǒng)也會幫你創(chuàng)建一個隱式的主鍵。這是因為InnoDB是把數(shù)據(jù)存放在B+樹中的,而B+樹的鍵值就是主鍵,在B+樹的葉子節(jié)點中,存儲了表中所有的數(shù)據(jù)。這種以主鍵作為B+樹索引的鍵值而構(gòu)建的B+樹索引,我們稱之為聚集索引。②非聚集索引(非聚簇索引):以主鍵以外的列值作為鍵值構(gòu)建的B+樹索引,我們稱之為非聚集索引。非聚集索引與聚集索引的區(qū)別在于非聚集索引的葉子節(jié)點不存儲表中的數(shù)據(jù),而是存儲該列對應(yīng)的主鍵,想要查找數(shù)據(jù)我們還需要根據(jù)主鍵再去聚集索引中進行查找,這個再根據(jù)聚集索引查找數(shù)據(jù)的過程,我們稱為回表。明白了聚集索引和非聚集索引的定義,我們應(yīng)該明白這樣一句話:數(shù)據(jù)即索引,索引即數(shù)據(jù)。利用聚集索引和非聚集索引查找數(shù)據(jù)前面我們講解B+樹索引的時候并沒有去說怎么在B+樹中進行數(shù)據(jù)的查找,主要就是因為還沒有引出聚集索引和非聚集索引的概念。下面我們通過講解如何通過聚集索引以及非聚集索引查找數(shù)據(jù)表中數(shù)據(jù)的方式介紹一下B+樹索引查找數(shù)據(jù)方法。利用聚集索引查找數(shù)據(jù)還是這張B+樹索引圖,現(xiàn)在我們應(yīng)該知道這就是聚集索引,表中的數(shù)據(jù)存儲在其中。現(xiàn)在假設(shè)我們要查找id=18并且idlt;40的用戶數(shù)據(jù)。對應(yīng)的sql語句為:MySQL1select*fromuserwhereid=18andidlt;40其中id為主鍵,具體的查找過程如下:①一般根節(jié)點都是常駐內(nèi)存的,也就是說頁1已經(jīng)在內(nèi)存中了,此時不需要到磁盤中讀取數(shù)據(jù),直接從內(nèi)存中讀取即可。從內(nèi)存中讀取到頁1,要查找這個id=18andidlt;40或者范圍值,我們首先需要找到id=18的鍵值。從頁1中我們可以找到鍵值18,此時我們需要根據(jù)指針p2,定位到頁3。②要從頁3中查找數(shù)據(jù),我們就需要拿著p2指針去磁盤中進行讀取頁3。從磁盤中讀取頁3后將頁3放入內(nèi)存中,然后進行查找,我們可以找到鍵值18,然后再拿到頁3中的指針p1,定位到頁8。③同樣的頁8頁不在內(nèi)存中,我們需要再去磁盤中將頁8讀取到內(nèi)存中。將頁8讀取到內(nèi)存中后。因為頁中的數(shù)據(jù)是鏈表進行連接的,而且鍵值是按照順序存放的,此時可以根據(jù)二分查找法定位到鍵值18。此時因為已經(jīng)到數(shù)據(jù)頁了,此時我們已經(jīng)找到一條滿足條件的數(shù)據(jù)了,就是鍵值18對應(yīng)的數(shù)據(jù)。因為是范圍查找,而且此時所有的數(shù)據(jù)又都存在葉子節(jié)點,并且是有序排列的,那么我們就可以對頁8中的鍵值依次進行遍歷查找并匹配滿足條件的數(shù)據(jù)。我們可以一直找到鍵值為22的數(shù)據(jù),然后頁8中就沒有數(shù)據(jù)了,此時我們需要拿著頁8中的p指針去讀取頁9中的數(shù)據(jù)。④因為頁9不在內(nèi)存中,就又會加載頁9到內(nèi)存中,并通過和頁8中一樣的方式進行數(shù)據(jù)的查找,直到將頁12加載到內(nèi)存中,發(fā)現(xiàn)41大于40,此時不滿足條件。那么查找到此終止。最終我們找到滿足條件的所有數(shù)據(jù),總共12條記錄:(18,kl),(19,kl),(22,hj),(24,io),(25,vg),(29,jk),(31,jk),(33,rt),(34,ty),(35,yu),(37,rt),(39,rt)。下面看下具體的查找流程圖利用非聚集索引查找數(shù)據(jù)讀者看到這張圖的時候可能會蒙,這是啥東西啊?怎么都是數(shù)字。如果有這種感覺,請仔細看下圖中紅字的解釋。什么?還看不懂?那我再來解釋下吧。首先,這個非聚集索引表示的是用戶幸運數(shù)字的索引(為什么是幸運數(shù)字?一時興起想起來的:-)),此時表結(jié)構(gòu)是這樣的。在葉子節(jié)點中,不再存儲所有的數(shù)據(jù)了,存儲的是鍵值和主鍵。對于葉子節(jié)點中的x-y,比如1-1。左邊的1表示的是索引的鍵值,右邊的1表示的是主鍵值。如果我們要找到幸運數(shù)字為33的用戶信息,對應(yīng)的sql語句為:MySQL1select

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論