mysql索引

今天看了一些關于MySQL相關的東西，來做一些碎碎念，寫這些可能只是覺得自己看東西老愛忘23333.

先來看一組MySQL數(shù)據(jù)，如圖我們要查看最后id=11的數(shù)據(jù)，如果我們不加索引的話會怎樣呢？

他會一條一條的比對，直到最后一條，加了索引他就不用一條一條比對了嗎？

其實也不是這樣理解的。

我們先來看他如何進行一條一條比對，我們數(shù)據(jù)庫中的數(shù)據(jù)是存儲在硬盤中的，這是一種持久化的數(shù)據(jù)，不同于我們

程序中的數(shù)據(jù)(程序中的數(shù)據(jù)是易失的，程序結束就沒了，這其實就是我們內存的特性)，如果我們需要比對，第一

步要做的是把數(shù)據(jù)庫硬盤中的數(shù)據(jù)加載進內存，例如比對開始，第一條數(shù)據(jù)，id=1從硬盤加載進內存，與我們程序中

的sql語句(select id from user where id=11)進行比對，發(fā)現(xiàn)id不等于11，于是接著把id=2加載進內存，如此

下去，直到id=11，程序結束。此過程我們可以發(fā)現(xiàn)如果我們要查詢id=11

要進行11次把數(shù)據(jù)從硬盤加載進內存的操作

這就是我們常說的磁盤IO操作，磁盤IO操作非常耗費時間的，僅僅這樣一個查詢就要11次IO操作……

我還有個不成熟的例子，我們大家都有那種一個軟件半天才打開的經歷吧，這就是一個把硬盤數(shù)據(jù)加載進內存的過程，

也就是磁盤IO操作，類比于我們現(xiàn)在這個表中的查詢，如果要進行11次這樣的操作，有點嚇人是不是。

那么我們如果可以在插入數(shù)據(jù)的時候同時維護一棵二叉排序樹，這樣我們在查找的時候是不是可以節(jié)省不少時間？

二叉排序樹就是一棵左兒子小于本身，右兒子大于本身的二叉樹，不詳細說了。這樣我們就可以從查找O(n)的

復雜度，降低到O(lgn)。但是又有問題了，如圖所示

事實上這樣的二叉排序樹非常常見，像不像我們的鏈表？鏈表相比于數(shù)組的壞處就是查找麻煩，這種退化為鏈表的

二叉排序樹已經沒有查找的優(yōu)越性了。由此人們又研究出來AVL排序樹，叫法很多，平衡樹啊，AVL查找樹啊都是這個。

如圖

平衡樹的確很好，但是還是有問題，平衡樹要求葉子節(jié)點的高度差不能大于1，這個要求其實過于苛刻，事實上隨便一個

操作都能打破這種平衡，平衡樹就需要左旋右旋來進行矯正，但是左旋右旋操作也是非常耗費時間的，所以就有了紅黑樹

紅黑樹先比較于平衡樹，最大的區(qū)別就在于他放寬了進行左旋右旋的條件。

但是我們知道MySQL索引底層用的也不是紅黑樹，其實是B+樹，那么B+樹又改進了紅黑樹什么特性呢，紅黑樹說到底還是

一種二叉樹，在我們數(shù)據(jù)量足夠大的情況下，二叉條件下樹的深度還是非常大的，避免不了進行很多次磁盤IO，B+樹簡單

來說就是一種多叉排序樹，將深度轉換為寬度。

總結

以上是生活随笔為你收集整理的mysql 深胡_Mysql胡说八道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。