一、碼場心得

你是個(gè)能吃苦的人嗎？

從前的能吃苦大多指的體力勞動(dòng)的苦，但現(xiàn)在的能吃苦已經(jīng)包括太多維度，包括：讀書學(xué)習(xí)&寂寞的苦、深度思考&腦力的苦、自律習(xí)慣&修行的苦、自控能力&放棄的苦、低頭做人&尊嚴(yán)的苦。

雖然這些苦擺在眼前，但大多數(shù)人還是喜歡吃簡單的苦。熬夜加班、日復(fù)一日、重復(fù)昨天、CRUD，最后身體發(fā)胖、體質(zhì)下降、能力不足、自抱自泣！所以有些苦能不吃就不吃，要吃就吃那些有成長價(jià)值的苦。

今天你堅(jiān)持了嗎？

如果一件小事能堅(jiān)持5年以上，那你一定是很了不起的人。是的，很了不起。人最難的就是想清楚了但做不到，或者偶爾做到長期做不到。

其實(shí)大多數(shù)走在研發(fā)路上的伙伴們，都知道自己該努力，但明明下好了的決心就是堅(jiān)持不了多久。直到有一天被瓶頸限制在困局中才會著急，但這時(shí)候在想破局就真的很難了！

MySQL為何不選擇平衡二叉樹

既然平衡二叉樹解決了普通二叉樹的問題，那么mysql為何不選擇平衡二叉樹作為索引呢?

索引需要存儲什么

讓我們想一想，如果我們要把索引存起來，那么應(yīng)該存哪些信息呢，它應(yīng)該存儲三塊信息：

• 索引的值：就是表里面索引列對應(yīng)的值。

• 數(shù)據(jù)的磁盤地址(通過磁盤地址找到當(dāng)前數(shù)據(jù))或者直接存儲整條數(shù)據(jù)。

• 子節(jié)點(diǎn)的引用：我們需要從根節(jié)點(diǎn)往下走，所以需要知道左右子節(jié)點(diǎn)的地址。 根據(jù)這三點(diǎn)，可以有如下大致的一個(gè)簡單的結(jié)構(gòu)圖：

上圖中數(shù)字表示的是索引的值，0x開頭的表示磁盤地址，根節(jié)點(diǎn)中存了左右節(jié)點(diǎn)的引用。

AVL樹用來存儲索引存在什么問題

我們知道，頁（Page）是 Innodb 存儲引擎用于管理數(shù)據(jù)的最小磁盤單位，頁的默認(rèn)大小為16KB。頁也就是上圖中的節(jié)點(diǎn)，每查詢一次節(jié)點(diǎn)就需要進(jìn)行一次IO操作，IO操作是一種非常耗時(shí)的操作，很多業(yè)務(wù)系統(tǒng)的瓶頸都是卡在IO操作上，所以如果我們需要提高查詢效率的辦法之一就是減少IO次數(shù)，那么問題就來了，AVL樹一個(gè)節(jié)點(diǎn)上只存了一個(gè)關(guān)鍵字(索引值)+一個(gè)磁盤地址+左右節(jié)點(diǎn)的引用，這是遠(yuǎn)遠(yuǎn)達(dá)不到16KB的，會浪費(fèi)了大量的空間。

上圖中如果我們要找到6這條數(shù)據(jù)，需要進(jìn)行3次IO(獲取一個(gè)節(jié)點(diǎn)就是一個(gè)IO操作)，如果這棵樹很高的話，就會進(jìn)行大量的IO操作，所以說AVL樹存在的最大問題就是空間利用不足，浪費(fèi)了大量空間，數(shù)據(jù)量大的時(shí)候就會成為一顆瘦高的樹，那么我們可以怎么改進(jìn)呢？答案很明顯了，那就是每個(gè)磁盤塊多存一點(diǎn)東西，也就是說每個(gè)磁盤多存幾個(gè)關(guān)鍵字，因?yàn)殛P(guān)鍵字越多，路數(shù)越多；路數(shù)越多，樹也就越矮越胖，相應(yīng)的操作IO次數(shù)就會越少。

多路平衡樹(Balanced Tree)

多路平衡樹簡稱B樹，又稱B-樹，和AVL樹一樣，B樹在枝節(jié)點(diǎn)和葉子節(jié)點(diǎn)存儲鍵值、磁盤地址、左右節(jié)點(diǎn)引用。請看下圖的一個(gè)多路平衡樹的示例：

B樹的特點(diǎn)

相比較AVL樹，B樹一個(gè)磁盤上可以存多個(gè)關(guān)鍵字(值)，而且有一個(gè)特點(diǎn)就是：

• 分叉數(shù)（路數(shù)）永遠(yuǎn)比關(guān)鍵字?jǐn)?shù)多1。 我們可以畫出如下簡圖(下圖中只畫了3路，即兩個(gè)關(guān)鍵字，實(shí)際取決于一頁能存儲多少個(gè)關(guān)鍵字)：

從上圖可以很明顯的看出，同樣高度的樹，B樹能存的數(shù)據(jù)遠(yuǎn)遠(yuǎn)大于平衡二叉樹。

B樹是如何查找數(shù)據(jù)的

以上圖為例，假如我們要找key=32這個(gè)數(shù)字，首先獲取到根節(jié)點(diǎn)，發(fā)現(xiàn)18小于key，所以往右邊走，獲取到右邊的數(shù)據(jù)，54和76，這時(shí)候遵循以下原則：

• key<54,命中最左邊分叉；

• key=54,直接命中，返回?cái)?shù)據(jù)；

• 54<key<76,走中間的一個(gè)分叉；

• key=76,直接命中，返回?cái)?shù)據(jù)；

• key>76，命中右邊分支； 這里因?yàn)閗ey=32，所以走得是第1條，命中左邊分支，這時(shí)候再去獲取左邊分支，獲取到32和50，比較發(fā)現(xiàn)key=32，命中，返回?cái)?shù)據(jù)。

從上面我們可以看出B樹效率相對于AVL樹，在數(shù)據(jù)量大的情況效率已經(jīng)提高了很多，那么為什么MySQL還是不選擇B樹作為索引呢？ 那么接下來讓我們先看看改良版的B+樹，然后再下結(jié)論吧！

B+樹

B+樹由B樹改良而來，屬于改良版的多路平衡查找樹。 首先讓我們來看看B+樹到底長什么樣呢：

對比B+樹，我們可以發(fā)現(xiàn)一個(gè)很明顯的區(qū)別就是葉子節(jié)點(diǎn)有一個(gè)箭頭指引而且從左到右是有序的。

InnoDB中使用的B+樹相比較于傳統(tǒng)B+樹，改進(jìn)之后的B+樹具有以下特點(diǎn)

InnoDB中B+樹的特點(diǎn)

• 它的關(guān)鍵字的數(shù)量是跟路數(shù)相等的。

• B+樹的根節(jié)點(diǎn)和枝節(jié)點(diǎn)中都不會存儲數(shù)據(jù)，只有葉子節(jié)點(diǎn)才存儲數(shù)據(jù)。而搜索到關(guān)鍵字不會直接返回，會到最后一層的葉子節(jié)點(diǎn)。

• B+樹的每個(gè)葉子節(jié)點(diǎn)增加了一個(gè)指向相鄰葉子節(jié)點(diǎn)的指針，它的最后一個(gè)數(shù)據(jù)會指向下一個(gè)葉子節(jié)點(diǎn)的第一個(gè)數(shù)據(jù)，形成了一個(gè)有序鏈表的結(jié)構(gòu)。

• 它是根據(jù)左閉右開的區(qū)間來檢索數(shù)據(jù)的 按照B+樹的特點(diǎn)，我們可以畫出一個(gè)存儲數(shù)據(jù)的簡圖，如下：

總結(jié)

談到面試，其實(shí)說白了就是刷題刷題刷題，天天作死的刷。。。。。

為了準(zhǔn)備這個(gè)“金三銀四”的春招，狂刷一個(gè)月的題，狂補(bǔ)超多的漏洞知識，像這次美團(tuán)面試問的算法、數(shù)據(jù)庫、Redis、設(shè)計(jì)模式等這些題目都是我刷到過的

并且我也將自己刷的題全部整理成了PDF或者Word文檔（含詳細(xì)答案解析），有需要的朋友可以戳這里即可免費(fèi)領(lǐng)取

66個(gè)Java面試知識點(diǎn)

架構(gòu)專題（MySQL，Java，Redis，線程，并發(fā)，設(shè)計(jì)模式，Nginx，Linux，框架，微服務(wù)等）+大廠面試題詳解（百度，阿里，騰訊，華為，迅雷，網(wǎng)易，中興，北京中軟等）

算法刷題（PDF）

x，Linux，框架，微服務(wù)等）+大廠面試題詳解（百度，阿里，騰訊，華為，迅雷，網(wǎng)易，中興，北京中軟等）**

[外鏈圖片轉(zhuǎn)存中…(img-aDhwjcuT-1621851217817)]

算法刷題（PDF）

總結(jié)

以上是生活随笔為你收集整理的程序员深度学习！mysql客户端工具免费绿色版的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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