索引：加速查詢的數據結構
一、索引設計原則
1. 經常查詢的字段，建議創建索引；
2. 索引不是越多越好：維護索引結構會佔用磁盤空間(每個索引是一個單獨的存儲結構)、影響增刪查改的性能(查：生成執行計劃時要考慮各個索引;可能用不到最佳索引； 增刪改：要維護每個索引的結構)；
3. 經常更新的表不要太多索引： 數據更新時會調整索引，消耗系統資源；
4. 數據量小的表不要創建索引、區分度低的字段不要建立索引： 索引起不到優化效果，維護索引結構反而消耗系統資源
5. 字段具有唯一性時，創建唯一索引能提高查詢速度；
6. 頻繁排列分組(group by、order by)的字段，如果待排序字段有多個，可以建組合索引
二、索引匹配規則
1. 最左前綴匹配原則，否則不會命中索引 (B+樹的存儲結構，從左向右匹配索引，如果是聯合索引則按建立聯合索引的順序存放，且sql中)
2. like，如果以%開頭，不會命中索引 (where name like "%張") (因爲索引是從左向右匹配)
3. 負向條件(!= / not in / not exists)查詢不會用到索引 ==> 實際跑了一下發現用到了索引！
4. 在屬性上進行計算不能命中索引(where id*3=3000，確實沒走到)
三、B樹和B+樹
其他結構：順序查找：O(n)
hash索引：無法滿足範圍查找、模糊查找。
二叉樹、紅黑樹：O(h) 大量數據時樹很高，IO次數多導致查找慢； 相鄰數據無指針關聯，不能範圍查找。
B樹的特點:
1. 所有節點都可以存儲數據。每個節點有多個關鍵字，每個關鍵字都是一個二元數組:[key,data]，key爲索引字段，value爲除索引外其他字段。
2. 一層層查找，本層找到數據，或者往對應區間下層的指針指向的節點遞歸查找。
3. 缺點：數據增刪時會破壞B樹的結構，需要對樹進行分裂、合併、轉移等操作保持結構，IO頻繁；
區間查找時可能會往返上下層遍歷，IO頻繁；
各層節點都存儲數據，所以每頁能存的關鍵字變少，樹的深度增加。
B+樹的特點：
1. 非葉子節點不存data，只存索引key。只有葉子節點才存key+data
2. 在葉子節點的尾巴上增加下一個相鄰葉子節點的頭結點指針(雙向鏈表)，把所有數據串起來。
3. 三層的B+樹能存儲大約2000萬條數據(即只需要3次IO)：InnoDB的索引節點大小默認16k，前兩層只存索引(假設主鍵id用bigint,佔8字節)+該區間的下層指針(6字節)，第三層存索引+完整記錄，假設每條記錄佔1k，一個節點存16條數據，即1170*1170*16。