今日推薦為啥查詢那么慢？

后端接口如何提高性能？

16 個(gè)寫代碼的好習(xí)慣

為什么不推薦使用BeanUtils屬性轉(zhuǎn)換工具

盤點(diǎn)阿里巴巴 34 個(gè)牛逼 GitHub 項(xiàng)目

常見代碼重構(gòu)技巧（非常實(shí)用）

來源：blog.csdn.net/that_is_cool/article/details/81069945

索引其實(shí)是一種數(shù)據(jù)結(jié)構(gòu)，在數(shù)據(jù)庫中，讀寫的比例是在10：1，所以如果每一次查找都全表查找的話，效率將會變的十分的低下。所以，本文將會按照題目，按部就班地講解MySql的索引。

##B樹和B+樹 B樹和B+樹算是數(shù)據(jù)結(jié)構(gòu)中出現(xiàn)頻率十分高的模型了，在筆者之前的幾篇博客，有對二叉查找樹和二叉平衡樹進(jìn)行過講解和代碼分析，但是那些都是在程序中使用比較多的樹，在數(shù)據(jù)庫中，數(shù)據(jù)量相對較大，多路查找樹顯然更加適合數(shù)據(jù)庫的應(yīng)用場景，接下來我們就介紹這兩類多路查找樹，畢竟作為程序員，心里沒點(diǎn)B樹怎么能行呢？

B樹：B樹就是B-樹，他有著如下的特性：

• B樹不同于二叉樹，他們的一個(gè)節(jié)點(diǎn)可以存儲多個(gè)關(guān)鍵字和多個(gè)子樹指針，這也是B+樹的特點(diǎn)；

• 一個(gè)m階的B樹要求除了根節(jié)點(diǎn)以外，所有的非葉子子節(jié)點(diǎn)必須要有[m/2,m]個(gè)子樹；

• 根節(jié)點(diǎn)必須只能有兩個(gè)子樹，當(dāng)然，如果只有根節(jié)點(diǎn)一個(gè)節(jié)點(diǎn)的情況存在；

• B樹是一個(gè)查找二叉樹，這點(diǎn)和二叉查找樹很像，他都是越靠前的子樹越小，并且，同一個(gè)節(jié)點(diǎn)內(nèi)，關(guān)鍵字按照大小排序；

• B樹的一個(gè)節(jié)點(diǎn)要求子樹的個(gè)數(shù)等于關(guān)鍵字的個(gè)數(shù)+1；

好了，話不多說，看看B樹的模型吧：

一個(gè)五階的B樹

由于B樹將所有的查找關(guān)鍵字都放在節(jié)點(diǎn)中，所以查找方式和二叉查找十分相像，比如說查找E:

先通過根節(jié)點(diǎn)找到了左子樹，再順序地遍歷左子樹，發(fā)現(xiàn)E在F和J的中間，于是查找葉子節(jié)點(diǎn)，順序遍歷關(guān)鍵字以后就可以返回E了，如果未能查到E，則表示沒有找到。

B+樹

人人都喜歡plus，B+樹就是這么一個(gè)plus，后頭所講解的索引，就是用的B+樹，我們先來看看他的特性吧：

• B+樹將所有的查找結(jié)果放在葉子節(jié)點(diǎn)中，這也就意味著查找B+樹，就必須到葉子節(jié)點(diǎn)才能返回結(jié)果；

• B+樹每一個(gè)節(jié)點(diǎn)的關(guān)鍵字個(gè)數(shù)和子樹指針個(gè)數(shù)相同；

• B+樹的非葉子節(jié)點(diǎn)的每一個(gè)關(guān)鍵字對應(yīng)一個(gè)指針，而關(guān)鍵字則是子樹的最大，或者最小值；

看看模型吧：

一個(gè)3階的B+樹

他的查找方式也是簡單粗暴的，和B樹十分像，只不過他會在葉子節(jié)點(diǎn)中找到目標(biāo)，比如我們找兔：

第一步比馬小，就會查找他的子樹，第二部比龍小，就會查找他的子樹，最后在葉子節(jié)點(diǎn)中的關(guān)鍵字命中目標(biāo)。

那么MySql是如何利用這數(shù)據(jù)結(jié)構(gòu)的呢？

MySql中的兩種常見存儲引擎

MySql當(dāng)然不止兩種搜索引擎了，但是本次我們說的B+樹索引，為接下來這兩種存儲引擎所用，一個(gè)是Innodb，一個(gè)Myisam。（搜索公眾號Java知音，回復(fù)“2021”，送你一份Java面試題寶典）

Innodb存儲引擎

Innodb使用的是B+樹，他存在有一個(gè)主鍵索引和輔助索引兩種索引，主鍵索引是在生成主鍵時(shí)就有的索引，他的葉子節(jié)點(diǎn)中存放的就是數(shù)據(jù)行，所以又稱之為聚集索引。

而另一類索引，輔助索引，就是我們?nèi)藶樾陆ǖ乃饕?#xff0c;他的葉子節(jié)點(diǎn)中存放的是主鍵，當(dāng)我們通過輔助索引查找到主鍵之后，再通過查找的主鍵去查找主鍵索引，我們看看兩種索引的結(jié)構(gòu)吧：

innodb主索引，其中葉子中存放的就是數(shù)據(jù)行innodb輔助索引，其中葉子存放的是主鍵

MyIsam存儲引擎

很顯然，MyIsam不可能再會用聚集索引了，雖然他用的是B+樹，但是他的主鍵索引和輔助索引沒有任何區(qū)別，都是在葉子中存儲數(shù)據(jù)行的物理地址，這也使得他的讀性能更高，我們來看他的模型吧：

MyIsam存儲引擎的主鍵索引MyIsam存儲引擎的輔助索引，存放的同樣是物理地址

區(qū)別

1、innodb支持事務(wù)，且默認(rèn)是Autocommit，所以每一條SQL語句都會封裝成一個(gè)事務(wù)，如果執(zhí)行多條事務(wù)，最好加上begin和commit。MyIsam不支持事務(wù)，也就無法回滾；

2、另外Innodb支持行鎖，MyIsam進(jìn)行寫操作會全表上鎖，所以MyIsam的寫操作性能會差些；

3、所以，在查詢較多的表中，使用MyIsam較優(yōu)，寫比較多的表，使用Innodb；

拓展--復(fù)合索引

我們都知道我們可以對一個(gè)列創(chuàng)建一個(gè)索引，但是什么是復(fù)合索引呢？

創(chuàng)建：

create?table?test( a?int, b?int, c?int, KEY?a(a,b,c) );

通過以上代碼我們就可以創(chuàng)建一個(gè)a、b、c三個(gè)字段的復(fù)合索引了，相對于維護(hù)三個(gè)索引，維護(hù)一個(gè)復(fù)合索引的開銷肯定是更低的。

但是復(fù)合索引需要滿足一個(gè)最左匹配原則，也就是他會依次查找a、b、c三個(gè)字段，當(dāng)左邊的字段未作為判斷條件時(shí)，就不會再去執(zhí)行接下來的索引了，測試如下：

EXPLAIN?DELETE?from?test where??a=1?and?c=?3?and?b?=2? 當(dāng)a、b、c都有的時(shí)候，他會繼續(xù)去匹配右邊的字段EXPLAIN?DELETE?from?test where??a=1?and?c=?3? 當(dāng)去除b時(shí)，發(fā)現(xiàn)復(fù)合索引只匹配到a就結(jié)束了，并不會匹配c推薦文章

• 14個(gè)項(xiàng)目！
  

• 一款小清新的 SpringBoot+ Mybatis 前后端分離后臺管理系統(tǒng)項(xiàng)目
  

• 47K Star 的SpringBoot+MyBatis+docker電商項(xiàng)目，附帶超詳細(xì)的文檔！
  

• 寫博客能月入10K？
  

• 一款基于 Spring Boot 的現(xiàn)代化社區(qū)（論壇/問答/社交網(wǎng)絡(luò)/博客）

更多項(xiàng)目源碼

• 這或許是最美的Vue+Element開源后臺管理UI

• 推薦一款高顏值的 Spring Boot 快速開發(fā)框架
  

• 一款基于 Spring Boot 的現(xiàn)代化社區(qū)（論壇/問答/社交網(wǎng)絡(luò)/博客）
  

• 13K點(diǎn)贊都基于 Vue+Spring 前后端分離管理系統(tǒng)ELAdmin，大愛

• 想接私活時(shí)薪再翻一倍，建議根據(jù)這幾個(gè)開源的SpringBoot

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的MySQL：从B树到B+树到索引再到存储引擎的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。