b+樹由b樹和索引順序訪問方法（isam）演化而來的。innodb儲存引擎表是索引組織表，即表中資料按照主鍵順序存放。而聚集索引（clustered index）就是按照每張表的主鍵構造一顆b+樹，同時葉子節點中存放的即為整張表的行記錄資料，也將聚集索引的葉子節點稱為資料頁。聚集索引的這個特性決定了索引組織表中資料也是索引的一部分。同b+樹資料結構一樣，每個資料頁都通過乙個雙向鍊錶來進行鏈結。精簡的b+樹的介紹：
b+樹是為磁碟或其他直接訪問輔助裝置設計的一種平衡查詢樹。在b+樹中，所有記錄節點都是按照鍵值的大小順序存放在同一層的葉子節點上，由各葉子節點指標進行連線。
b+樹索引的本質就是b+樹在資料庫中的實現。b+索引在資料庫中有乙個特點是高扇出性，因此在資料庫中，b+樹的蓋度一般都在
2~4層，這也就是說查詢某一鍵值的行記錄時最多隻需要2到4次io， 這倒不錯。因為當前一般的機械硬碟每秒至少可以做100次io，2~4 次的io意味查詢時間只需 0.02 ~ 0.04 秒。資料庫中的b+樹索引可以分為聚集索引 (clustered index) 和輔助索引 (secondary index)，內部都是b+樹，即高度平衡。聚集索引與輔助索引不同的是，葉子節點存放的是否是一整行的資訊。
由於實際的資料頁只能按照一棵b+樹進行排序，因此每張表只能擁有乙個聚集索引。
由於定義了資料的邏輯順序，聚集索引能夠特別快地訪問針對範圍值的查詢。
許多資料庫文件會告訴讀者：聚集索引按照順序物理地儲存資料。聚集索引的另一好處是，它對於主鍵的排序查詢和範圍查詢速度非常快。葉子節點的資料就是使用者所要查詢的資料。但是試想一下，如果聚集索引必須按照特定順序存放物理記錄，則維護成本顯得非常之高。。所以聚集索引的儲存並不是物理上連續的，而是邏輯上連續的。這其中有兩點：一是前面說過的頁通過雙向鍊錶鏈結，頁按照主鍵的順序儲存；另一點是每個頁中的記錄也是通過雙向鍊錶進行維護的，物理儲存上可以同樣不按照主鍵儲存。
如使用者需要查詢一張註冊使用者的表，查詢最後註冊的10位使用者，由於b+樹索引是雙向鍊錶的，使用者可以快速找到最後乙個資料頁，並取出10條記錄，若用命令explain進行分析，可得：
可以看到雖然使用order by對記錄進行排序，但是在實際過程中並沒有進行所謂的filesort操作，而這就是因為聚集索引的特點。
另乙個是範圍查詢（range query），即如果要查詢主鍵某一範圍內的資料，通過葉子節點上層中間節點就可以得到頁的範圍，之後直接讀取資料頁即可，又如：
執行explain得到了 mysql資料庫的執行計畫（execute plan），並且在rows列中給出了乙個查詢結果的預估返回行數。要注意的是，rows代表的是乙個預估值，不是確切的值，如果實際執行這句sql的查詢，可以看到實際上只有9946行記錄：
對於輔助索引（secondary index，也稱為非聚集索引），葉子節點並不包含行記錄的全部資料。葉子節點除了包含鍵值以外，每個葉子節點中的索引行中還包含了乙個書籤（bookmark）。該書籤用來告訴innodb儲存引擎**可以找到與索引相對應的行資料。書籤就是相應行資料的聚集索引鍵（主鍵）。
當通過輔助索引來尋找資料時，innodb儲存引擎會遍歷輔助索引並通過葉級別的指標獲得指向主鍵索引的主鍵，然後再通過主鍵索引來找到乙個完整的行記錄。
InnoDB聚集索引，輔助索引，覆蓋索引，聯合索引
聚集索引就是按照每張表的主鍵id和指向葉子結點的偏移量作為b 樹的非葉子結點，行記錄資料作為葉子結點，葉子結點也稱之為資料頁，且葉子結點通過雙向鍊錶連線。由於一張資料表只有乙個主鍵，因此一張資料表也只能有乙個聚集索引。聚集索引結構是b 樹且葉子結點通過雙向鍊錶連線，所以對於主鍵的排序查詢和範圍查詢都...
聚集索引與非聚集索引
非聚集索引也是堆結構？其實sqlserver有幾種頁面型別 資料都使用一頁一頁來儲存，就像windows的記憶體也是使用頁面來組織的 感興趣的朋友可以了解下，希望本文可以增加你們對非聚集索引結構的理解。我們知道sqlserver的資料行的儲存有兩種資料結構 a 堆b b樹 binary 二叉樹 資料...
聚集索引與非聚集索引
一 聚集索引概念 漢語字典的正文本身就是乙個聚集索引。比如，我們要查 安 字，就會很自然地翻開字典的前幾頁，因為 安 的拼音是 an 而按照拼音排序漢字的字典是以英文本母 a 開頭並以 z 結尾的，那麼 安 字就自然地排在字典的前部。如果您翻完了所有以 a 開頭的部分仍然找不到這個字，那麼就說明您的...