mysql底層數據接結構：B+Tree
為什么索引的數據結構沒有選用二叉樹？
二叉樹的底層數據原理是 左子元素 < 父元素 < 右子元素
列如插入1~7會變成一個鏈表
假設查找的元素是7 他會先從跟節點找，進行一次磁盤IO，把根節點 load 到內存跟要查到的要素做對比 ， 先把1 load到內存跟要查找的7做對比一看 7>1 然后再去找1的右子樹 ~~ 直到進行7次磁 盤IO找到7。
為什么沒有選用紅黑樹(又叫平衡二叉樹)？
JDK1.8以后 HashMap底層的鏈表采用的紅黑樹做優化
假設數據量大的時候他的縱向會延長，比如說500萬條數據他的樹干高度是30的話，萬一查找的數據就在葉子節點上 需要經過30次的磁盤IO
為什么選用紅B+Tree（btree的變種）？
磁盤一次IO交互大概是（4K/16K）mysql一個節點是16K（1638）
B+Tree非葉子節點不存value，只存索引key（冗余），比btree可以放更多的 索引
葉子節點包含所有索引字段
葉子節點有雙向的指針，提高區間的訪問的性能。
為什么mysql推薦索引主鍵是自增Bigint類型？
Mysql的指針大概占6B bigint 類型的索引占 8b 6+8=14b
Mysql一個節點是16k 16k/14b = 1170個索引 （一個節點可以存1170個索引）
假設索引+一條數據占用1K，那么葉子節點可以放16個，那么葉子節點可以放多少呢？如果按照上面的來看公式是 1170 * 1170 * 16 約等於2100萬條數據
而且mysql的根節點是常駐內存的，假設要查找的數據是在根節點上where條件沒索引是非常慢的（慢查詢），如果where條件有索引那么是毫秒級別就能查出來的（基本兩次磁盤IO）
如果是UUID當主鍵的話那么存索引的時候需要一個字符一個字符的比較（比字符的ASCII碼，國標碼）沒有直接的int效率高，如果沒有加索引那么他在后台會選擇唯一字段來維護這張表
，如果沒有唯一那么他后台會自動生成一個RowId來幫忙維護這張表
Mysql 的數據放在data文件里 （5.7以下的默認在MySql安裝目錄下）data文件里每個文件對象這Mysql的每一個數據庫 .frm存的表結構 .MYI存的是索引 .MYD存的是數據 .ibd存的是索引＋數據
Mysql大部分用的存儲引擎有兩種：
Innodb：一個文件葉子節點包含索引字段的數據，innodb就是所說的聚集索引（就是索引跟數據在一個文件），支持事務。
MYSAM：誇兩個文件，從 .MYI到 .MYD，這種誇兩個文件的就叫非聚集索引不支持事務。
Mysql還有一種Hash索引為什么用的特別少？
因為hash不能做范圍查找 ，假如where條件是 column<5 那么他就跟沒加索引一樣 但是b+tree葉子節點有雙向指針的查找就非常快