mysql優化（二）索引

B-tree索引

能夠理解爲「排序好的快速查找結構」，從大的方面看用的都是平衡樹，但具體的實現上各引擎稍微有不一樣，好比嚴格地說NDB使用的是T-tree

---

假設一張表內有7個用戶，讓你取出5號用戶，你只能從前到後挨個對比，而後在第五次找到；運氣好id爲1一次就找到，運氣差id爲7要找7次才能找到，若是有1億條數據，平均找n/2次也得找5000萬次才能找到

---

如今有btree就大不同了，如圖

仍是找5號用戶，第一次判斷5>4,到6的節點，判斷6<5，到5的節點，3次就找到了。這裏結果可能和上面平均結果差很少，但設想若是是42億數據（int型的最大值），上圖找法平均要找21億次，而btree樹只要找32次就必定能找到。
由於樹的第一層，放2的0次方，樹的第二層放2的1次方，第三層放2的2次方，以此類推32層的樹就徹底放完了42億數據，因此運氣再差查詢也只要32次
找到5以後，就能獲取存儲在磁盤上位置行的信息，因此找數據的流程實際上是如今索引樹上跑，找到索引，而後根據索引信息去取數據，以myisam爲例，假設有一張user表，你會發現它其實有3個文件

• user.frm 表的結構說明
• user.myd 數據
• user.myi 樹

hash索引

在memory裏默認是hash索引，hash的理論查詢時間複雜度爲O(1),意味着無論有幾十億條數據，理論上只用查詢一次就能找到。
那hash是怎麼實現的呢，簡單地說，哈希索引就是採用必定的哈希算法，把鍵值換算成新的哈希值，檢索時不須要相似B+tree那樣從根節點到葉子節點逐級查找，只需一次哈希算法便可馬上定位到相應的位置，速度很是快。
但有優勢就有缺點，hash也是否是萬能的，它依然有一些缺點和限制：

• hash索引僅僅能知足=、in、<=>查詢，不能使用範圍查詢，只能精準查詢
• 沒法利用前綴索引
• 排序沒法優化
• 不能避免表掃描