索引

使用索引，會提前存儲被索引字段對應行的磁盤文件地址指針，做一次IO就能查找到數據。

二叉樹

遞增的索引不適合用二叉樹來維護，因為遞增的id會導致二叉樹退化成為鏈表，這樣建立索引的效果和不建立索引的差別不大。因此MySQL不使用二叉樹做索引。

數據結構可視化網站

紅黑樹

單邊增長不平衡時，紅黑樹會自動平衡。
JDK1.8之后，HashMap使用的就是紅黑樹。
在某些場景下，紅黑樹也會存在問題：樹的高度會一直增長，數據量大的時候，還是會有很多次IO。

B樹

B樹是對紅黑樹的改造，讓一個節點能夠存儲更多的元素。

為什么不把所有元素都加載進一個節點，放進內存中？

• 占用內存過大；一次磁盤IO有大小限制，加載不過來，會很慢
• 沒有必要把一個節點搞得太大。

使用show global status like'Innodb_page_size'查看MySQL默認設置一個葉節點（頁）的值：16Kb

B+樹

MySQL底層使用的是B+樹，是對B樹的改造。
把非葉子節點的data數據都挪到了葉子結點上去存儲，這樣，在16kb大小固定的情況下，一個葉子節點在橫向上能存放更多的索引。

例如，查找30這個元素對應的data的過程：
第一次，將15 56 77 load 進內存：
第二次，將15 20 49 load 進內存
第三次，將20 30 load 進內存，進而取出30對應的data

因此，如果添加了合適的索引，只需要進行2-3次磁盤IO，就可以找到數據。
如果不添加索引的話，需要一行一行去找，十分緩慢。

關于存儲引擎

存儲引擎是表級別的，不同的表可以有不同的存儲引擎

主鍵自帶主鍵索引。

MyISAM引擎的查詢過程：

• 先去索引文件中查找指針
• 再去指針的位置磁盤中把data查詢出來

數據和索引是分開存儲的，它的葉子結點只存儲了數據在磁盤對應文件的地址。

MySQL數據文件存儲在哪里？都有哪些文件？如圖：

InnoDB引擎的查詢過程：

InnoDB的主鍵索引是聚集索引。（什么是稀疏索引？稀疏索引就是非聚集索引）
.ibd文件同時存儲索引和數據，以B+樹的結構組織起來，在葉子節點包含了一條記錄（行）的所有數據。

常見問題

為什么InnoDB表必須有主鍵，并且推薦使用整型的自增主鍵？

MySQL InnoDB引擎設計數據默認使用B+樹來組織。
如果沒設置主鍵，MySQL會自動找一個能夠作為主鍵的字段，作為索引去維護。
如果MySQL找不到合適的主鍵，MySQL會自己維護一個隱藏列，用這個隱藏列做索引。

為什么推薦使用自增的主鍵？
自增的主鍵有利于維護B+樹（每次都向尾部追加），而如果不自增的話，可能會插入到B+數中間位置的某個節點中，而每個節點的大小是有限制的。超出限制后，為了保持樹的平衡，會造成葉節點分裂，導致插入性能下降。

用UUID作為主鍵怎么樣？

在B+數查找的過程需要進行多次比較大小。UUID是作為字符串存儲的，而用整型數字較大小效率更高，并且整型的索引在存儲的時候占用的磁盤空間更小。

用Hash作為索引怎么樣？

用Hash的話，select * from t where col1 > 6這樣的范圍查詢無法加快查詢速度
而如果使用B+樹，葉子結點的（雙向）指針提高了范圍查詢的速度。

分庫分表怎么辦？是不是UUID更方便？

分庫分表也可以使用整型。
參考雪花算法：Twitter 開源的分布式 id 生成算法。其核心思想就是：使用一個 64 bit 的 long 型的數字作為全局唯一 id。在分布式系統中的應用十分廣泛，且ID 引入了時間戳，基本上保持自增的。這 64 個 bit 中，其中 1 個 bit 是不用的，然后用其中的 41 bit 作為毫秒數，用 10 bit 作為工作機器 id，12 bit 作為序列號。

聯合索引是什么結構？

幾個字段一起存儲在節點匯總。排序方式：按照字段逐個進行排序，維護B+樹從左到右依次遞增。
使用聯合索引時，注意最左前綴原則：如果a b c三列加了索引，查找時如果根據a b查找，能走索引。如果根據b c查找，無法走索引。（不能跳過某一個索引，直接用后面的索引）

總結

以上是生活随笔為你收集整理的【MySQL】Mysql索引优化与底层数据结构深入剖析 - 笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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