嘟嘟在上兩個文章里面簡單粗糙的講了講關於MySql存儲引擎的一些特性以及選擇。個人感覺如果面試官給我機會的話，至少能說個10分鍾了吧。只可惜有時候生活就是這樣：骨感的皮包骨頭了還在那美呢。牢騷兩句，北京的夏天真的是熱的膠粘。昨天上班兒忙到了晚上11點多，本想着昨兒晚上就把關於數據庫優化的文章寫完了，今天就能寫個關於高並發的。結果嘟嘟這個小屋子就好比那商務大洗浴的汗蒸房一樣。嘟嘟昨夜屬實有點暈乎。只好晚上鍛煉鍛煉身體之后看了一集《長安十二時辰》。。。。。話不多說，今天學學關於索引的一些問題。
索引簡介
優點
（索引可以大大大大大大的提高查詢性能！）
1.通過創建唯一性索引，保證數據庫每一行數據的唯一性
2.大大加快檢索速度
3.加速表和表之間的連接
4.減少查詢中分組和排序的時間
5.通過使用索引，在查詢的過程中，使用查詢優化器，提高系統性能
缺點
1.創建索引和維護索引消耗時間，這種時間隨數據量增加而增加
2.索引需要占用物理空間，如果建立聚簇索引，占用空間更大
3.如果表中增刪改，索引需要動態維護，降低數據的維護速度
什么字段適合創建索引
1.常搜索的列上，加快搜索速度
2.主鍵列上（MySql 在主鍵上面默認增加索引）
3.常用的連接列上（外鍵），加快連接速度
4.在經常根據范圍進行搜索的列上創建索引，因為索引已經排序，其指定范圍是連續的 （a between xxx and xxx 但是不是 in （5，10，15）這種）可以在a上面加上索引
5.經常需要排序的列上創建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加速查詢時間
6.經常使用where子句中的列上創建索引，加快條件的判斷速度
需要注意的一點是 ：比如在 where f1。。。 and f2。。。，那么我們在字段f1或者f2上建立索引是沒有用的，只有在f1和f2上同時建立索引才有用
什么樣的字段不適合創建索引
1.查詢中很少使用到的，或者參考的列就沒必要加索引
2.數據值相對少的列也不適合。舉個極端點的栗子：people 字段有20萬條。sex 字段有三條（男，女，不男不女） 在sex字段上面添加索引就是沒有用的
3.大文本數據不應該增加索引。
4.經常增刪改，但是查詢比較少的時候就不需要做索引啦
停停停停！因為索引的具體介紹涉及到了關於查找機制（怎么查找一個東西更快的方法）的一些問題，所以嘟嘟先在這里惡補一下查找的相關機制，便於后面繼續學習索引種類。
1.樹是什么玩應？（B-Tree ，這 Tree 那Tree的）
首先一棵小樹，必須先有一個根，然后依靠這個根來開枝散葉。就形成了一棵樹。
2.怎么查詢快？
設想一下，如果在查找一大堆數據的過程中，我們能依靠某些辦法，去舍棄一些沒有必要去查找的東西。那么查找的速度就會比一個一個查的速度快的多。
基於以上兩點，網上給大家扒下來一棵能夠讓我們查找數據時候快一些的樹
6那個地方是根， 258 是葉子，37是分支，235678的值叫做鍵值
1. 這棵樹的形成是有一定的規則的：
根的左邊（235）叫做左子樹，根的右邊（78）叫做右子樹，首先第一個規則就是右子樹的鍵值要大於根鍵值，左子樹相反。
2. 給定的這6個數字235678為什么就把根選成6了？因為6是中間數，至於為什么不是5？嘟嘟個人覺得也可以，就這么畫唄：
3.我們把每一個數值對應的那個點叫做節點。那么我這棵樹也滿足上邊的那個規則：相對於每一個節點，他左側的子節點都會比他小，右側的子節點都會比他大。
4.這么做有什么好處呢？用嘟嘟自己畫的那張圖為例子奧，比如嘟嘟要查6這個數字需要查幾次？（1）先查到了5，發現6比5大 ，根據規則，往右側走到了7。（2）發現6比7小根據規則往左側走到了6！查完了。用了兩步。那么正常按照順序查詢的話，就不一定查多少次了。
5.那么6個隨機數字，在我們按照上述規則進行排序之后想要查詢一個數字，需要查詢多少次？（1）查詢第一個數字5需要一步.（2）查詢第二層數字3或者7需要2次並且有兩種可能，意思是你想查3需要兩次，你想查7也得需要兩次。（3） 同理，在查詢第三層的數字的時候3種可能，並且第三層的任意數字你都需要查三次。所以平均下來就是：
（1+2+2+3+3+3）/（1+2+3）=2.3次平均
相比正常排序的查詢（1+2+3+4+5+6）/6=3.5次 查詢確實快了一些。原因就是通過比大小的方式，將一些沒有必要查詢的數字給舍棄了。
6.聽說這種樹叫做二叉樹。而二叉樹也有別的畫法：
（很明顯這種數的查詢效率就底下） （1+2+3+4+5+5）/6=3.3次
針對上面那個效率低下的二叉樹，就又引入一條規則，進而產生了一種平衡二叉樹（AVL Tree）
1.這條規則就是，對於任何一個節點下面的兩個子樹的高度差都<=1
嘟嘟個人推測這種平衡的機制可以保證搜索效率的最大化（因為嘟嘟時間有限，這個結論是看上面三顆樹對比之下的效率感覺的）
2.如果在一棵已經平衡的樹上面增加一個數，減少一個數，或者修改一個數，樹的平衡就可能被打破了（嘿嘿嘿，嘟嘟想起來文章開頭寫的，如果某些字段經常發生增刪改就不太適合使用索引，因為平衡機制被打破了得話，就得重新耗費資源區重構這種平衡）。
3.如果平衡被打破，需要重構（通過一種叫做旋轉的辦法保證二叉樹的平衡，詳細的流程嘟嘟推薦大家看看別的博客），旋轉的方式嘟嘟在這里就不再贅述了，意思就是通過位置的調換，保證二叉樹的原則就是了。
B-Tree（平衡多路查找樹）
1.B-Tree 是針對磁盤等外存儲設備設計的一種平衡查找樹
2.為什么會出現B-Tree 這種查找機制呢？ 因為InnoDB 存儲引擎，InnoDB管理磁盤的最小單位是頁（16KB），而磁盤存儲數據的最小單位是磁盤塊block（遠遠小於16KB），這就造成了，InnoDB在進行數據讀取（比如查找的時候）會將連續的好幾個磁盤塊讀入（老子必須讀夠16KB！）。這是個硬傷。因為讀取也是浪費資源的。而InnoDB你一次讀的太多了。
3.針對2中讀的太多的問題。如果有一種查找機制可以繼續減少查找的時候IO的次數，就會降低資源的浪費。
4.B-Tree誕生了。
下面這張圖片能夠比較完美的詮釋B-Tree的特性
嘟嘟在別的哥哥的博客上扒下來的圖片。第一眼看的時候可能是因為天氣太熱，有點暈乎。但是睡一覺起床以后再看它（MD豁然開朗）
1.首先每一個磁盤塊都是一個節點,每個節點都有三個指針兩條數據。
2.數據都是以【key,data】的方式存儲的。每條指針都存儲子節點的地址。兩條數據的key值是從小到大排序。
3.於是乎以磁盤塊1為例子，就形成了三個區間 {小於17的，17至35的，35以上的}，並分別有不同的指針指向對應的磁盤塊。
4.對比平衡二叉樹的話，在單次的選擇上，二叉樹只能選擇出到底我要查詢的數是比現在大還是比現在小（也就是2選1），而B-Tree每一次可以選擇出來我要查的數具體在哪個區間（多選一），導向更加精確，自然查詢次數會更少。
關於索引和查找的相關介紹。嘟嘟就講到這里啦，下次嘟嘟會繼續學習關於具體索引的知識。以上寫的東西嘟嘟基本上是粗淺理解了一下然后現學現賣。畢竟嘟嘟是個新手，對數據結構與算法什么的並沒有太高的要求。但是理解一下，既為以后打下一個引子，又不至於學的腦袋疼。