1. mysql使用的是什麽結構的索引？

1). MyISAM引擎使用B+Tree作為索引結構，葉節點的data域存放的是數據記錄的地址。因此，MyISAM中索引檢索的算法為首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，

然後以data域的值為地址，讀取相應數據記錄。

2). InnoDB也使用B+Tree作為索引結構，但具體實現方式卻與MyISAM截然不同。

a. 第一個重大區別是InnoDB的數據文件本身就是索引文件。MyISAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。而在InnoDB中，表數據文件本身就是按B+Tree組織的一個索引結構，

這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此InnoDB表數據文件本身就是主索引。

b. 第二個與MyISAM索引的不同是InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。聚集索引這種實現方式使得按主鍵的搜索十分高效，

但是輔助索引搜索需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。

2. mysql索引優化策略

1). 對 where,on,group by,order by 中出現的列使用索引。

2). 為較長的字符串使用前綴索引。

3). 不要過多創建索引，除了增加額外的磁盤空間外，對於DML操作的速度影響很大，因為其每增刪改一次就得從新建立索引。

4). 使用組合索引，可以減少文件索引大小，在使用時速度要優於多個單列索引。

5). 維度高的列創建索引。如數據表中存在8行數據a,b ,c,d,a,b,c,d這個表的維度為4。

6). 不建議使用過長的字段作為主鍵，因為所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。

7). 用非單調的字段作為主鍵在InnoDB中不是個好主意，因為InnoDB數據文件本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時數據文件為了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增字段作為主鍵則是一個很好的選擇。

8). 如果查詢條件中含有函數或表達式，則MySQL不會為這列使用索引（雖然某些在數學意義上可以使用）。

3. 為什麽索引要使用B+Tree?

一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗，相對於內存存取，I/O存取的消耗要高幾個數量級，所以評價一個數據結構

作為索引的優劣最重要的指標就是在查找過程中磁盤I/O操作次數的漸進復雜度。換句話說，索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數。

由於磁盤順序讀取的效率很高（不需要尋道時間，只需很少的旋轉時間），因此對於具有局部性的程序來說，預讀可以提高I/O效率。預讀的長度一般為頁（page）的整倍數。頁是計算機管理存儲器的邏輯塊，硬件及操作系統

往往將主存和磁盤存儲區分割為連續的大小相等的塊，每個存儲塊稱為一頁（在許多操作系統中，頁得大小通常為4k），主存和磁盤以頁為單位交換數據。當程序要讀取的數據不在主存中時，會觸發一個缺頁異常，此時系統會向

磁盤發出讀盤信號，磁盤會找到數據的起始位置並向後連續讀取一頁或幾頁載入內存中，然後異常返回，程序繼續運行。

上文說過一般使用磁盤I/O次數評價索引結構的優劣。先從B-Tree分析，根據B-Tree的定義，可知檢索一次最多需要訪問h個節點。數據庫系統的設計者巧妙利用了磁盤預讀原理，將一個節點的大小設為等於一個頁，這樣每個節點

只需要一次I/O就可以完全載入。為了達到這個目的，在實際實現B-Tree還需要使用如下技巧：

每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁裏，加之計算機存儲分配都是按頁對齊的，就實現了一個node只需一次I/O。B-Tree中一次檢索最多需要h-1次I/O（根節點常駐內存），漸進復雜度為

(h)=O(logdN)O(h)=O(logdN)。一般實際應用中，出度d是非常大的數字，通常超過100，因此h非常小（通常不超過3）。

綜上所述，用B-Tree作為索引結構效率是非常高的。

而紅黑樹這種結構，h明顯要深的多。由於邏輯上很近的節點（父子）物理上可能很遠，無法利用局部性，所以紅黑樹的I/O漸進復雜度也為O(h)，效率明顯比B-Tree差很多。

上文還說過，B+Tree更適合外存索引，原因和內節點出度d有關。從上面分析可以看到，d越大索引的性能越好，而出度的上限取決於節點內key和data的大小：

dmax=floor(pagesize/(keysize+datasize+pointsize))dmax=floor(pagesize/(keysize+datasize+pointsize))

floor表示向下取整。由於B+Tree內節點去掉了data域，因此可以擁有更大的出度，擁有更好的性能。

4. 數據庫優化方案：http://www.cnblogs.com/Jtianlin/p/8832896.html

5. Explain用法：

1. B-樹,這裏的 B 表示 balance( 平衡的意思),B-樹是一種多路自平衡的搜索樹 它類似普通的平衡二叉樹，不同的一點是B-樹允許每個節點有更多的子節點。

2. B-樹有如下特點:

1). 所有鍵值分布在整顆樹中；

2). 任何一個關鍵字出現且只出現在一個結點中；

3). 搜索有可能在非葉子結點結束；

4). 在關鍵字全集內做一次查找,性能逼近二分查找；

3. B+樹是B-樹的變體，也是一種多路搜索樹, 它與 B- 樹的不同之處在於:

1). 所有關鍵字存儲在葉子節點出現,內部節點(非葉子節點並不存儲真正的 data)

2). 為所有葉子結點增加了一個鏈指針

4. 紅黑樹等數據結構也可以用來實現索引，但是文件系統及數據庫系統普遍采用B-/+Tree作為索引結構。MySQL 是基於磁盤的數據庫系統,索引往往以索引文件的形式存儲的磁盤上,索引查找

過程中就要產生磁盤I/O消耗,相對於內存存取，I/O存取的消耗要高幾個數量級,索引的結構組織要盡量減少查找過程中磁盤I/O的存取次數。為什麽使用B-/+Tree，還跟磁盤存取原理有關。

5. 局部性原理與磁盤預讀:由於磁盤的存取速度與內存之間鴻溝,為了提高效率,要盡量減少磁盤I/O.磁盤往往不是嚴格按需讀取，而是每次都會預讀,磁盤讀取完需要的數據,會順序向後讀一定長度的數據放入內存。

而這樣做的理論依據是計算機科學中著名的局部性原理：

當一個數據被用到時，其附近的數據也通常會馬上被使用

程序運行期間所需要的數據通常比較集中

由於磁盤順序讀取的效率很高(不需要尋道時間，只需很少的旋轉時間)，因此對於具有局部性的程序來說，預讀可以提高I/O效率.預讀的長度一般為頁(page)的整倍數。

6. MySQL(默認使用InnoDB引擎),將記錄按照頁的方式進行管理,每頁大小默認為16K(這個值可以修改).linux 默認頁大小為4K

7. B-/+Tree索引的性能分析:

際實現B-Tree還需要使用如下技巧：

每次新建節點時，直接申請一個頁的空間，這樣就保證一個節點物理上也存儲在一個頁裏，加之計算機存儲分配都是按頁對齊的，就實現了一個結點只需一次I/O。

假設 B-Tree 的高度為 h,B-Tree中一次檢索最多需要h-1次I/O（根節點常駐內存），漸進復雜度為O(h)=O(logdN)O(h)=O(logdN)。一般實際應用中，出度d是非常大的數字，通常超過100，因此h非常小（通常不超過3）。

而紅黑樹這種結構，h明顯要深的多。由於邏輯上很近的節點（父子）物理上可能很遠，無法利用局部性，所以紅黑樹的I/O漸進復雜度也為O(h)，效率明顯比B-Tree差很多。

8. 為什麽使用 B+樹

1). B+樹更適合外部存儲,由於內節點無 data 域,一個結點可以存儲更多的內結點,每個節點能索引的範圍更大更精確,也意味著 B+樹單次磁盤IO的信息量大於B-樹,I/O效率更高。

2). Mysql是一種關系型數據庫，區間訪問是常見的一種情況，B+樹葉節點增加的鏈指針,加強了區間訪問性，可使用在範圍區間查詢等，而B-樹每個節點 key 和 data 在一起，則無法區間查找。

9. MySQL索引實現:

1). MyISAM引擎使用B+Tree作為索引結構，葉節點的data域存放的是數據記錄的地址。data域保存數據記錄的地址。因此，MyISAM中索引檢索的算法為首先按照B+Tree搜索算法搜索索引，

如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應數據記錄。MyISAM的索引方式也叫做“非聚集”的，之所以這麽稱呼是為了與InnoDB的聚集索引區分。

2). InnoDB索引實現:雖然InnoDB也使用B+Tree作為索引結構，但具體實現方式卻與MyISAM截然不同。

a. 第一個重大區別是InnoDB的數據文件本身就是索引文件。從上文知道，MyISAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。而在InnoDB中，表數據文件本身就是按B+Tree組織的一個索引結構，

這棵樹的葉節點data域保存了完整的數據記錄。這個索引的key是數據表的主鍵，因此InnoDB表數據文件本身就是主索引。

b. 第二個與MyISAM索引的不同是InnoDB的輔助索引data域存儲相應記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。

10. 了解不同存儲引擎的索引實現方式對於正確使用和優化索引都非常有幫助，例如知道了InnoDB的索引實現後，就很容易明白為什麽不建議使用過長的字段作為主鍵，因為所有輔助索引都引用主索引，

過長的主索引會令輔助索引變得過大。再例如，用非單調的字段作為主鍵在InnoDB中不是個好主意，因為InnoDB數據文件本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時數據文件為了維持B+Tree的特性

而頻繁的分裂調整，十分低效，而使用自增字段作為主鍵則是一個很好的選擇。

11. 理論上索引對順序是敏感的，但是由於MySQL的查詢優化器會自動調整where子句的條件順序以使用適合的索引

12. 如果通配符%不出現在開頭，則可以用到索引，但根據具體情況不同可能只會用其中一個前綴。(title LIKE ‘Senior%‘;)

13. 很不幸，如果查詢條件中含有函數或表達式，則MySQL不會為這列使用索引（雖然某些在數學意義上可以使用）。

14. 上文討論過InnoDB的索引實現，InnoDB使用聚集索引，數據記錄本身被存於主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小為一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，

因此每當有一條新的記錄插入時，MySQL會根據其主鍵將其插入適當的節點和位置，如果頁面達到裝載因子（InnoDB默認為15/16），則開辟一個新的頁（節點）。

如果表使用自增主鍵，那麽每次插入新的記錄，記錄就會順序添加到當前索引節點的後續位置，當一頁寫滿，就會自動開辟一個新的頁。

這樣就會形成一個緊湊的索引結構，近似順序填滿。由於每次插入時也不需要移動已有數據，因此效率很高，也不會增加很多開銷在維護索引上。

如果使用非自增主鍵（如果身份證號或學號等），由於每次插入主鍵的值近似於隨機，因此每次新紀錄都要被插到現有索引頁得中間某個位置：

此時MySQL不得不為了將新記錄插到合適位置而移動數據，甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉，此時又要從磁盤上讀回來，這增加了很多開銷，同時頻繁的移動、分頁操作造成了大量的碎片，

得到了不夠緊湊的索引結構，後續不得不通過OPTIMIZE TABLE來重建表並優化填充頁面。

因此，只要可以，請盡量在InnoDB上采用自增字段做主鍵。

參見：

MySQL索引背後的數據結構及算法原理：http://blog.codinglabs.org/articles/theory-of-mysql-index.html

B+樹介紹：https://www.cnblogs.com/wade-luffy/p/6292784.html

由 B-/B+樹看 MySQL索引結構：https://segmentfault.com/a/1190000004690721

主碼索引、聚集索引、非主碼索引（輔助索引）、唯一索引、外鍵索引、復合索引、非主碼索引、聚集主碼（聚集索引）、單列索引、多列索引、普通索引等：http://www.cnblogs.com/xiangyangzhu/p/index.html

淺談算法和數據結構: 十 平衡查找樹之B樹：http://www.cnblogs.com/yangecnu/p/Introduce-B-Tree-and-B-Plus-Tree.html

AVL平衡二叉樹中旋轉操作的本質及其實現：https://blog.csdn.net/vesper305/article/details/13614403

樹型結構：http://www.cnblogs.com/xrq730/p/5187032.html

mysql數據庫索引