參考文章:
可以以接近二分的效率檢索資料而不是線性檢索效率，乙個m階b -數 樹的要求如下：
根結點至少擁有兩顆子樹（存在子樹的情況下）；
除了根結點以外，其餘每個分支結點至少擁有 m/2 棵子樹；
所有的葉結點都在同一層上；
有 k 棵子樹的分支結點則存在 k-1 個關鍵碼，關鍵碼按照遞增次序進行排列；
關鍵字數量需要滿足ceil(m/2)-1 <= n <= m-1；
由於b+樹的資料都儲存在葉子結點中，分支結點均為索引，方便掃庫，只需要掃一遍葉子結點即可，但是b樹因為其分支結點同樣儲存著資料，我們要找到具體的資料，需要進行一次中序遍歷按序來掃，所以b+樹更加適合在區間查詢的情況，所以通常b+樹用於資料庫索引，而b樹則常用於檔案索引。
這都是由於b+樹和b具有這不同的儲存結構所造成的區別，以乙個m階樹為例。
（1）關鍵字的數量不同；b+樹中分支結點有m個關鍵字，其葉子結點也有m個，其關鍵字只是起到了乙個索引的作用，但是b樹雖然也有m個子結點，但是其只擁有m-1個關鍵字。
（2）儲存的位置不同；b+樹中的資料都儲存在葉子結點上，也就是其所有葉子結點的資料組合起來就是完整的資料，但是b樹的資料儲存在每乙個結點中，並不僅僅儲存在葉子結點上。
（3）分支結點的構造不同；b+樹的分支結點僅僅儲存著關鍵字資訊和兒子的指標（這裡的指標指的是磁碟塊的偏移量），也就是說內部結點僅僅包含著索引資訊。
（4）查詢不同；b樹在找到具體的數值以後，則結束，而b+樹則需要通過索引找到葉子結點中的資料才結束，也就是說b+樹的搜尋過程中走了一條從根結點到葉子結點的路徑。
b+ tree 是基於 b tree 和葉子節點順序訪問指標進行實現，它具有 b tree 的平衡性，並且通過順序訪問指標來提高區間查詢的效能。
在 b+ tree 中，乙個節點中的 key 從左到右非遞減排列，如果某個指標的左右相鄰 key 分別是 keyi 和 keyi+1，且不為 null，則該指標指向節點的所有 key 大於等於 keyi 且小於等於 keyi+1。
進行查詢操作時，首先在根節點進行二分查詢，找到乙個 key 所在的指標，然後遞迴地在指標所指向的節點進行查詢。直到查詢到葉子節點，然後在葉子節點上進行二分查詢，找出 key 所對應的 data。
插入刪除操作會破壞平衡樹的平衡性，因此在插入刪除操作之後，需要對樹進行乙個**、合併、旋轉等操作來維護平衡性。
innodb 的 b+tree 索引分為主索引和輔助索引。主索引的葉子節點 data 域記錄著完整的資料記錄，這種索引方式被稱為聚簇索引。因為無法把資料行存放在兩個不同的地方，所以乙個表只能有乙個聚簇索引。輔助索引的葉子節點的 data 域記錄著主鍵的值，因此在使用輔助索引進行查詢時，需要先查找到主鍵值，然後再到主索引中進行查詢。
innodb 儲存引擎有乙個特殊的功能叫「自適應雜湊索引」，當某個索引值被使用的非常頻繁時，會在 b+tree 索引之上再建立乙個雜湊索引，這樣就讓 b+tree 索引具有雜湊索引的一些優點，比如快速的雜湊查詢。
myisam 儲存引擎支援空間資料索引（r-tree），可以用於地理資料儲存。空間資料索引會從所有維度來索引資料，可以有效地使用任意維度來進行組合查詢。
必須使用 gis 相關的函式來維護資料。
mysql建表 索引以及SQL效能優化
1前言2 設計部分 2.1設計表注意事項 2.1.1 定義字段型別 盡可能精確地定義字段型別，包括型別和長度 如不要以字元型別宣告純數字字段，業務上tinyint夠用的情況避免定義為int等。2.1.2 盡可能使用not null null需要更多的 更多的檢查和特殊的索引邏輯。所以大多數時候應該使...
mysql索引 回表 記錄下mysql索引以及回表
mysql資料庫的innodb引擎所有的表都預設建立在索引之上的，也就是聚集索引，而主鍵就是聚集索引，所以主鍵只能建乙個。普通索引也就是非聚集索引，可以多個。索引的資料結構是b 樹也就是平衡樹。查詢資料的時候根據索引查詢資料所在位置然後取到資料。查詢普通索引的時候是先根據普通索引找到主鍵再根據主鍵定...
mysql索引以及慢SQL優化記錄 轉慕課
mysql索引介紹以及慢sql優化 索引介紹 略 sql優化說明 慢sql優化例子select count from task where status 2 and operator id 20839 and operate time 1371169729 and operate time 1371...