索引的底層資料結構有：
1 樹tree，準確的說是b+樹
2 hash
時間複雜度對比：
hash的時間o(1)
tree的o(logn)
為什麼索引採用b+樹，而不採用hash這種結構？
hash這種結構對與獲取單條記錄時的查詢效率是要比b+樹效率要高的，
但是對與資料的範圍查詢效率就很低，特別是對於資料量大的時候（10萬 甚至百萬級別的資料），
為什麼低？它是根據欄位值算出獲取乙個hash值，然後根據hash值找到在索引表中查詢出hash值對應的資料行，它的索引沒有按順序儲存
b+樹:是一種多路平衡樹，乙個橫向存放多個節點，並且它的非葉子節點都只存放指向子節點的索引指標，不存放資料。所有
非葉子節點都存放乙個節點在葉子節點上，並且這個葉子節點是乙個有序的列表結構。
當我們查乙個範圍資料時，通過b+樹搜尋
多路：一課樹每個節點最多可以擁有大於2個子節點的樹
平衡樹： 一顆樹左子樹和右子樹保持相對平衡，不會出現一邊層級特別多，一邊層級特別少的情況
為什麼不用二叉樹？
二叉樹為非平衡樹，如果是有序遞變的資料，很有可能就會變成左邊樹層級過高，或則右邊樹的層級過高，甚至是退化成煉表。
層級過高為什麼就不能用了呢？
假設是1,2,3,4,5,6這樣的資料，如果我們要找到底部6這個資料，就要進行6次io（載入磁碟資料進記憶體，索引是在磁碟檔案中以表的形式存在的）才能找到。如果按一次io10ms計算，60ms也不算什麼。但是假設是100萬呢？1001000010ms，也就是10000s，換算成分鐘也就是167，所以這種結構肯定是不行的。
為什麼不用紅黑二叉樹？
紅黑二叉樹一種平衡樹，雖然它不會出現有一樹的層級過高的情況，但是它還是沒有從根本上解決樹的層級問題，隨著資料量增大，樹的層級會越來越高。要遍歷葉子節點的資料io消耗還是過高。
為什麼沒有採用b樹，或則說b-樹？
b樹雖然雖然通過多路平衡樹解決了樹的高度問題，但是它對與訪問資料的查詢效率還是低下的，對於資料訪問在非葉子節點和葉子節點都有的範圍，它不僅非葉子節點的遍歷還需要做葉子節點的遍歷。
Mysql索引底層資料結構
想要了解索引，首先要知道索引到底是什麼呢 索引是幫助mysql高效獲取資料的排好序的資料結構 通俗來講就好比喻一本書，那這本書的目錄就好比做索引 索引儲存在檔案裡 儲存引擎是myisam的索引檔案儲存在 myi檔案中，儲存引擎是innodb的索引檔案儲存在 idb檔案中 通常資料庫中的資料就是存在硬...
索引底層資料結構和演算法
索引是高效 排序好的資料結構。為什麼不用hash結構，hash雖然單個快，但是範圍慢 陣列結構的，查詢慢，需要遍歷。二叉樹結構的，如果資料是從小到大的插入就會屬於單邊資料，一樣速度慢。紅黑樹結構，雖然能夠實現自動的平衡樹，但是如果資料量非常大的時候，還是會出現層次特別高。btree結構，是提高乙個節...
MySQL索引底層資料結構詳情
目錄 為什麼是b 樹而不是b樹？首先看看b樹和b 樹在結構上的區別 b樹結構 b 樹 可以看到 首先需要了解聚簇索引和非聚簇索引。聚簇索引 在聚簇索引中，葉子頁包含了行的全部資料，節點頁值包含索引列。innodb通過主鍵聚集資料，如果沒有定義主鍵則選擇乙個唯一的非空索引列代替 如果沒有這樣的索引，i...